Ledger

Twenty to thirty percent of invoices fail three-way match and drop into an exception queue that a team clears by hand — chasing buyers for missing receipts, vendors for corrected invoices, and approvers for tolerance overrides. On the receivables side, payments arrive without clean remittance advice, so cash sits unapplied while DSO climbs and collections chases customers who have already paid. Both queues are structurally identical: high-volume, rules-heavy, judgment-light work that nobody has enough headcount to clear.

• Exception backlogs create late-payment penalties and forfeited early-settlement discounts.
• Unapplied cash overstates receivables and triggers collections against paying customers.
• Remittance advice arrives as PDF, email body or bank narrative — three formats, none structured.
• Every manual resolution is undocumented reasoning, which is precisely what an auditor asks for.

Ledger operates on the exception itself rather than the happy path. On the payables side agents classify the break — quantity variance, price variance, missing goods receipt, duplicate, tolerance-eligible — then gather the evidence needed to resolve it, drafting vendor and buyer correspondence where a fact is missing. On the receivables side agents parse unstructured remittance from any channel, propose invoice-level allocations against open items including partial and deduction cases, and post within confidence thresholds. Everything below threshold escalates with its working shown. The ERP remains the system of record; Ledger writes through it under a bounded-autonomy policy set per exception class.

Deterministic matching already handles the clean cases — that is why they never reach the queue. What remains are precisely the items rules cannot close: a remittance in prose, a short payment with an implied deduction reason, an invoice whose line descriptions don't align to the PO's. These require reading unstructured evidence and reasoning about intent, which is a language-model problem, not a rules problem. Confidence thresholds convert that into something a controller will accept: the system acts where it is certain, escalates where it is not, and shows its reasoning either way.

PAYABLES

Three-way-match exception resolution, tolerance handling

RECEIVABLES

Cash application, remittance matching, deduction coding

INPUTS

Structured ERP data + unstructured PDF, email, bank narrative

AUTONOMY

Confidence-thresholded per exception class, human escalation

AUDIT

Full evidence chain and rationale retained per posting

SYSTEM OF RECORD

Incumbent ERP; Ledger writes through it

1. 01Exceptions typed and triaged automatically on arrival rather than worked in receipt order.
2. 02Evidence assembled per exception — PO, receipt, contract terms, and how similar breaks were treated before.
3. 03Vendor and buyer chase correspondence drafted with the specific missing fact named, queued for approval.
4. 04Remittance parsed from any format, including prose bank narratives with no structured reference.
5. 05Partial payments and deductions allocated at invoice line level with a proposed reason code.
6. 06Every posting carries its reasoning and evidence chain, exportable for audit.

100%

Postings with retained evidence chaindesign intent

• PROCURE-TO-PAYHub for Accounts Payable Automation→
• CONTROLS & ASSURANCEHub for Automated Invoice Validation→
• REVENUE CYCLEHub for Hospital Claims Denials Management→