Three stages. The middle one is where the language model lives — and it is metered openly.
Trial balances or intercompany ledgers per entity (Excel/CSV), the invoices and credit notes behind them (PDF or scans), bank statements, and the email thread where the two sides argued about the 50-dollar gap.
Normalises every document into transactions with provenance, runs deterministic matching (amount, counterparty, period, reference — tolerance rules you set), then reads the unmatched items against invoices and emails to propose a reason: FX rounding, bank fee netted, timing, duplicate, missing document.
A reconciliation workbook with matched / explained / open items, cited explanations linked to the source page, draft adjusting entries, confirmation-letter drafts per counterparty, and a PBC evidence pack with an index.
| Pair · ref | A books / B books | Status | Explanation |
|---|---|---|---|
HK Trading Ltd → SG Holdings Pte INV-20931 | 42,180.00 42,180.00 | matched | |
SG Holdings Pte → HK Trading Ltd CN-00412 | −3,600.00 −3,600.00 | matched | |
HK Trading Ltd → DE GmbH INV-20944 | 18,250.00 18,200.00 | explained | Bank fee EUR 50 netted by DE — statement p.3 line 14 |
DE GmbH → HK Trading Ltd INV-7781 | 9,900.00 — | open | No invoice received; DE statement p.1 — request copy |
SG Holdings Pte → DE GmbH INV-0552 | 27,000.00 27,310.50 | explained | FX at booking date vs settlement date; diff 310.50 — draft JE #3 |
Illustrative output.
Token usage scales with documents, not with seats: each close reads every invoice page, statement and email thread for every entity pair. A 12-entity group with 400 intercompany invoices a month is roughly 20–60 million tokens per close. Matching itself is deterministic code and costs nothing; the model is spent only on reading and explaining.
We are onboarding a small number of design partners with real documents and real deadlines. Tell us what you work on and we will set up a workspace with your material.