Post your first payable-to-pending transaction
Clone the Formance Ledger on GitHub, run it locally, and post the payable-to-pending transaction from this article against your own vendor accounts.
Accounts payable (AP) automation needs a core ledger underneath it because the AP tool routes money, but the ledger records the money. Mixing those two roles causes duplicate payouts and unreconciled statements.
B2B ACH payments alone carried 8.08 billion payments worth $63.11 trillion in 2025, and most of that volume moves through tools that were never designed to be the source of truth.
When a payout job retries and pays twice, or when the bank statement and AP tool disagree on which invoices settled, tracing one payable from approval to settlement means manually joining the AP tool, the bank feed, and the enterprise resource planning (ERP) system.
A core ledger, a database where every liability, payment, and settlement is written as a balanced transaction that can never be edited or deleted, records every transaction to secure financial records for reconciliation, prevents duplicate payments, and preserves transaction history.
AP automation software ingests supplier invoices, routes them through approval rules, and triggers payouts on a payment rail.
AP automation software replaces the manual queue of PDF attachments, email approvals, and hand-keyed bank instructions. The software reads the vendor, amount, currency, and due date off the invoice, applies thresholds to decide who approves, picks a rail and a date, and pushes the payment out. On the return path, the software marks the invoice paid and syncs a transactional journal to the ERP.
Automating invoice capture and payment routing removes duplication errors. In February 2024, a Gartner survey of accountants found that a third make several financial errors, and over half (59%) make several errors per month.
The AP tool owns workflow, including who approves an invoice, when to pay it, and which general ledger (GL) code the expense hits.
The core ledger owns the money, including what you owe each vendor and how each payment moves from a rail to settled against the bank.
AP automation moves money on rails the AP tool does not own, so without a core ledger underneath, no single system can prove what was owed, what was paid, and what settled.
The missing ledger causes duplicate payouts, unreconciled statements, and missing audit trails.
AP automation requires a core ledger for three reasons: editable workflow rows, overwritten status columns, and missing transaction history.
Anyone with permission can edit a workflow row, and it has no counterparty. The workflow cannot prove that payables, pending payouts, and settled cash add up to zero. Reviewers see the current row, but not the sequence of edits behind it.
When the AP tool flips an invoice from approved to paid on a rail acknowledgment, the earlier state is gone. A failed payout that later reverses cannot be reconstructed from the current value, because the previous values were overwritten.
A core ledger writes every state change as an append-only transaction, so payables, pending payouts, settlements, and reversals all remain queryable.
Formance is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability, and it stores each payable's history in a per-vendor account. The transaction sequence stays secure with you, regardless of which AP tool sits on top.
AP automation with a core ledger requires five prerequisites to execute properly, spanning tooling, accounts, rails, infrastructure, and rollout.
With the five prerequisites in place, the steps below show how each state transition wires the AP tool to the ledger.
The account names are illustrative, and the transactions are written in Numscript, Formance’s language for describing financial transactions.
Integrating AP automation with a core ledger takes five steps: connecting the AP tool to the ledger, mapping invoice data to accounts, configuring approval and payment rules and workflows, automating posting and reconciliation, and maintaining audit records.
Connecting AP automation software to the core ledger means the AP tool calls the ledger over an API at each state transition.
Approval, payout initiation, settlement, and failure each trigger one API call that writes one transaction to the ledger. The ERP receives its journal from the core ledger and not from the AP tool.
Invoice capture is the exception. The AP tool extracts vendor, amount, currency, due date, and line items and holds the data, but no transaction fires yet.
Mapping invoice data to ledger accounts means defining the account tree once and mapping every invoice field to a source or destination.
Four branches cover the Acme example below:
The vendor ID selects the merchant payable account, the cost center selects the accrued expense account, the rail selects the pending account and external boundary, and the currency is the asset on each posting.
The AP tool handles GL coding and the three-way match against the purchase order and receipt, while the core ledger receives only the approved amount.
The match state (matched, variance, or disputed) never becomes a transaction, because a disputed invoice is not yet a liability.
The coding step produces the source account for recognition. For Acme, the account is @platform:expenses:operations:accrued.
Configuring approval rules and payment workflows keeps approval thresholds and routing in the AP tool.
The AP tool also picks the rail, and the core ledger only enforces that the transaction balances and the source account has enough to send.
Execute this decision test for any new feature: if it moves or reserves money, it is a transaction; if it changes who can act, it is workflow.
A new approver tier is workflow. A hold on a disputed vendor's balance reserves money, so a disputed-vendor hold is a transaction.
The final approver's decision fires the first core ledger transaction. The first transaction moves EUR 1,250,000 from @platform:expenses:operations:accrued (the source posting) to @merchants:acme:payabled (the destination posting).
This transaction is expressed in Numscript as such:
// SUPPLIER_INVOICE_APPROVED
// Event: recognize Acme's EUR 1,250,000 invoice as a payable
send [EUR/2 125000000] (
source = @platform:expenses:operations:accrued
destination = @merchants:acme:payable
)
set_tx_meta("event_type", "supplier_invoice_approved")
set_tx_meta("invoice_id", "inv001")
The accrual account allows a negative balance because it carries the expense's offsetting side.
Intermediate approvals, rejections, and re-routes stay in the AP tool.
Automating ledger posting and reconciliation requires an idempotency key minted at approval and automated matching between pending transactions and bank lines.
Attach the idempotency key to the pending transaction and the rail submission, and reuse the key on every retry. A repeat submission returns the first result instead of a second payment.
The idempotency key defends against a discrepancy when the orchestrator submits to the rail, dies before recording the result, and restarts with no memory of having submitted.
Store the key-to-result record in a strongly consistent store, so two workers racing on the same key cannot both win.
The payout transaction moves the balance from @merchants:acme:payable to @platform:banks:main:sepa:pending, and the rail's settlement event fires a second transaction to @external:sepa:acme.
The pending transaction says the money is committed to a rail and can no longer pay Acme a second time. The transaction below sends EUR 1,250,000, in minor units, from Acme's payable account to the SEPA pending account.
Both postings commit together, or nothing commits. If the payable balance cannot cover the amount, the core ledger refuses the whole transaction.
// SUPPLIER_PAYOUT_INITIATED
// Event: commit Acme's EUR 1,250,000 payable to the SEPA payout rail
send [EUR/2 125000000] (
source = @merchants:acme:payable
destination = @platform:banks:main:sepa:pending
)
set_tx_meta("event_type", "supplier_payout_initiated")
set_tx_meta("payout_id", "pyt001")
Rail acceptance is provisional, and the pending account records the provisional state. Each rail's settlement rules decide when the next transaction can fire.
When SEPA reports settlement, a second transaction moves the same amount from @platform:banks:main:sepa:pending to @external:sepa:acme and stores the rail reference and settlement time as metadata.
// SUPPLIER_PAYOUT_SETTLED
// Event: SEPA confirms settlement of Acme's EUR 1,250,000 payout
send [EUR/2 125000000] (
source = @platform:banks:main:sepa:pending
destination = @external:sepa:acme
)
set_tx_meta("event_type", "supplier_payout_settled")
set_tx_meta("payout_id", "pyt001")
set_tx_meta("rail_reference", "SEPA-REF-98765")
set_tx_meta("settled_at", "2025-03-14T10:22:00Z")
A failed payout creates a new transaction that moves the amount back from the pending account to the payable account. The original pending transaction stays where it was written.
Corrections use the same append-only pattern. A transaction dated today with an effective date in October keeps both the original and the correction visible to accruals, value-added tax (VAT), and vendor statements.
Automated reconciliation matches pending transactions against rail acknowledgments and settled transactions against bank statement lines.
Automated reconciliation also compares the payable balance with the ERP's open-item list. When payouts settle from an omnibus account, the bank line is an aggregate and the core ledger splits the aggregate back to individual payables by rail reference.
Maintaining audit traceability requires transactions chained by cryptographic reference so that the full history of every payable can be recomputed and verified.
Chaining each transaction to the previous transaction lets an auditor retrace the sequence and detect modified or missing records. The core ledger provides the missing record in the database, outside the AP tool's admin rights.
A bi-temporality query, which reads balances "as known" at the cut-off, lines up the internal ledger view and the external bank view at the same point in time. The query result can anchor the reconciliation record used by finance and external auditors.
The fastest way to see whether a core ledger fits your AP stack is to run one payable through it end to end.
Pick a real vendor invoice from last month, map it to the four-branch account tree:
Then post the approval and payout transactions against a local ledger before wiring anything to your AP tool.