Financial Management

Why this is a runtime problem, not a CRUD problem

Every growing business eventually collides with the same wall: journal entries live in a spreadsheet, supplier invoices live in email, bank reconciliation is a monthly fire drill, and nobody agrees on which number is correct. The root cause is not a missing screen — it is that double-entry bookkeeping is a constraint system, not a data store. Debits must equal credits before posting. A fiscal period must be open before an entry can land in it. A journal entry that was prepared by one accountant must not be posted by the same person. None of these rules fit neatly into a generic form builder.

A candid scope note. AuraBoot Finance covers the operational core: GL, AR, AP, journal approval workflows, supplier invoices with three-way matching, payment recording, bank reconciliation, expense claims, cost centers, and financial reporting. It is not a country-specific accounting compliance suite. It does not ship statutory chart-of-accounts for individual jurisdictions, built-in e-invoicing connectors for every country's tax authority, or localized VAT return filing. If your primary requirement is regulatory filing for a specific country, evaluate that gap honestly before choosing this solution. What AuraBoot provides is a clean, configurable operational layer on which country-specific compliance logic can be layered — either as your own plugin or via the optional tax-compliance plugin for supported regions.

With that scope clear: the full approval-and-posting pipeline is a command graph, not a hand-coded controller chain. The fiscal period lifecycle is a first-class state machine. Segregation of duties between preparers and approvers is enforced by the permission system — not by a comment in the code.

Data model summary

The Finance plugin ships 30 models across six functional areas:

• GL core: fin_account (hierarchical chart of accounts, five account types), fin_fiscal_period (monthly periods with open / soft-close / hard-close / locked lifecycle), fin_journal_entry + fin_journal_line (double-entry vouchers with approval workflow), fin_gl_balance (period-aggregated debit/credit balances).
• AR / AP: fin_ar_transaction (customer receivables from shipments or manual invoices), fin_ap_transaction (vendor payables from receipts), fin_supplier_invoice + fin_supplier_invoice_line (supplier invoice capture), fin_three_way_match (PO vs receipt vs invoice matching with tolerance and hold resolution), fin_payment (payment / receipt records linked to AR / AP with auto-journal generation).
• Expenses: fin_expense_claim (employee reimbursement with draft / pending / approved / paid lifecycle).
• Banking: fin_bank_account, fin_bank_statement + fin_bank_statement_line, fin_reconciliation (statement-line-to-journal matching).
• Multi-currency: fin_currency (ISO 4217 master), fin_exchange_rate (rate history); all journal entries carry both transaction-currency and base-currency totals.
• Cost accounting: fin_cost_center, fin_cost_element, fin_cost_allocation_rule, fin_standard_cost, fin_cost_variance.
• Reporting / KPI: fin_report_template + fin_report_line, fin_financial_report, fin_voucher_template, fin_kpi_definition + fin_kpi_snapshot, fin_restatement.

Key commands

The solution ships over 60 commands. The journal entry state machine is the clearest illustration of the constraint enforcement:

The fin:post_journal_entry command carries a handler field that invokes server-side Java logic. No amount of client-side validation replaces this: the handler is the only place that atomically validates balance and updates GL in the same transaction.

Invoice-to-payment lifecycle

  Supplier Invoice arrives
          |
          v
  [fin_supplier_invoice: draft]
          |
     submit
          |
          v
  [submitted]
          |
     approve / reject
          |
          v
  [approved] ──reject──> [rejected] ──resubmit──> [submitted]
          |
          v
  Three-Way Match created (fin_three_way_match)
   PO amount vs receipt amount vs invoice amount
          |
     within tolerance?
     /           \
   yes            no
    |              |
    v              v
  [match: approved]  [match: hold] ──resolve hold──> [approved]
    |
    v
  AP Transaction created (fin_ap_transaction)
    |
    v
  Payment recorded (fin_payment)
    |
    v
  Journal Entry auto-generated → posted to GL

Permission example

A realistic Finance team has at least two tensions to encode: separation of duties (the person who prepared a journal entry should not be the one who posts it) and team segmentation (AR staff should not see or touch AP transactions).

Segregation of duties — journal posting:

• Role fin_accountant holds fin.financial.manage — can create, submit, and post entries.
• The approval step (fin:approve_journal_entry) requires fin.financial.admin.
• In practice, companies configure the approval step as mandatory for any entry above a threshold and assign fin.financial.admin only to Finance Managers. The preparer can submit but cannot approve their own entry.

AR / AP team segregation:

• AR Specialist role: fin.financial.read, fin.payment.manage (record receipts against AR) — no fin.supplier_invoice.manage, no fin.bank_recon.manage.
• AP Specialist role: fin.supplier_invoice.manage, fin.payment.manage (record payments against AP) — no fin.financial.admin (cannot approve or post GL entries).

Field-level cost-center masking:

• Cost Accountant role holds fin.cost.read and fin.cost.manage — can see fin_cost_center allocation rates and standard cost cards.
• AR / AP roles do not hold fin.cost.read — cost-center breakdown fields are hidden on their journal-line views.

All five permission layers (RBAC, org scope, ReBAC, ABAC, field-level) are evaluated in order by the same platform pipeline used in every other use case.

How to get it

• Community: install the plugin from source: aura plugin publish plugins/finance --yes, then run aura exec fin:init_chart_of_accounts to seed a default chart of accounts.
• Standard: white-label the platform and ship the Finance plugin as part of your vertical.
• Professional: get the Finance solution with pre-wired menus, roles, dashboards, and the optional tax-compliance extension for supported regions.
• Enterprise: same package plus managed period-close orchestration, country-specific compliance packs as separate verticals, advanced multi-entity consolidation, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Managed period-close orchestration (automated soft-close checks, hard-close gate enforcement across entities, reconciliation completion gating), country-specific compliance packs (statutory chart-of-accounts, jurisdiction-level VAT return filing, e-invoicing bureau connectors) delivered as separately versioned verticals, and advanced multi-entity consolidation with intercompany elimination are commercial-only capabilities. The open-core GL / AR / AP / payment runtime described above is the same in every edition.

Next steps

• System overview — how plugins, commands, and the runtime fit together
• Command pipeline — the execution contract enforced by fin:post_journal_entry
• Permissions — the five-layer model used in the SoD and team-segregation examples above
• Plugin manifest — how the Finance plugin declares its 30 models and 60+ commands