Cases / Accounting · Document-to-ledger platform
Client under NDA Documents and integrations

A client month now closes in four hours instead of three days, and a document reaches the ledger in two minutes instead of twelve.

3 days → 4 hours
to close a client month
12 min → 2 min
per incoming document
~3 mo
to the full loop

The client is under NDA, so the industry and size are given as a range. The figures are the client’s own, comparing the periods before and after launch; on similar projects the result landed on both sides of these numbers. Run the numbers on your own volumes →

Context

Qualified accountants spent half the day retyping details out of PDFs.

An outsourced accounting firm, 10–15 people, 30–40 clients on the books. Source documents arrived however they arrived: by email, in messengers, as a batch of scans at the end of the month, sometimes on paper. An accountant opened each one, read off the counterparty, the amount, the tax and the date, and typed them into the accounting system by hand. Around twelve minutes a document, and half of that was not accounting — it was retyping. Reconciliation ran the same way: the bank statement on one side, the ledger on the other, line by line and by eye. A discrepancy surfaced on the third day of the close, and finding its cause took another day. Some documents simply went missing between an inbox and a folder and resurfaced a quarter later. Work on a client was split into parts across several people rather than owned end to end, so a missing document or an unexplained line bounced between them before anyone could answer for it. The close was capped by people rather than by data: the peak fell on the same five days every month, and in those days the firm could not take on a new client because there was nobody to give it to.

Solution

One intake for every document, and reconciliation that does not wait for the close.

The same stack as on our other projects: Python and Django at the core, PostgreSQL as the source of truth for the document, the counterparty and the entry. We did not replace the accounting system — it stayed the system of record and reporting, and the platform exchanges data with it. A document lands in one intake whatever channel it came from: mailbox, messenger, upload, scan. The model reads off the details, the platform checks them against the counterparty card and the contract, scores its confidence field by field, and either posts the document itself or puts it in a queue for a person to look at. Low confidence is not an error, it is a route.

Architecture
Email and messengerssource documentsScans and uploadsany formatBank statementslines and balancesCounterparty cardscontracts and detailsPlatform coredocument · counterparty · entryAccounting systementriesReview queueby confidenceReconciliationdiscrepanciesReportingwith audit trailClientmissing documents
What we built

Six loops in three months.

The order was set by the money: first the thing that removes the manual entry, then reconciliation, then reporting.

01
One intake for source documents
Email, messengers and uploads converge on a single queue. A document stops falling between channels, and whoever has to chase a client for a missing one can see what is missing.
02
Extraction and posting
Details are read off automatically and the document reaches the accounting system without being retyped. Twelve minutes became two.
03
A review queue driven by confidence
A person looks at what the model is unsure about, or at what disagrees with the contract, rather than at everything in turn. The work still splits across several people — it now splits by exception instead of by folder.
04
Continuous bank reconciliation
Lines match as they arrive, so a discrepancy surfaces on the day it appears rather than on the third day of the close.
05
Reconciliation with counterparties
Statements are assembled and sent out from inside the system, and the replies land in the same exception queue instead of in somebody’s inbox.
06
Close and reporting
Recurring reports assemble themselves with an audit trail: for every figure you can see which documents it was built from. A client month closes in about four hours instead of three days.
Before and after

Before and after.

Before
One document12 min
Closing a client month3 days
Entering detailsby hand
Bank reconciliationat the close
Finding a discrepancyup to a day
Lost documentssurfaced a quarter later
Reviewevery document
After
One document2 min
Closing a client month4 hours
Entering detailsautomatic
Bank reconciliationcontinuous
Finding a discrepancythe day it appears
Lost documentsnone
Reviewexceptions only
Limits
What stayed with people, deliberately.
The decision on a disputed document. The system shows what does not add up; a person decides.
Methodology — how an unusual transaction should be recorded.
Talking to the client about missing documents. The reminder is automatic, the conversation is not.
Signing off the reporting.
Stack
Python Django PostgreSQL LLM (replaceable) Accounting system exchange Bank statements Email and messengers Monitoring and alerts
Straight about the bottleneck

The bottleneck was data entry, not reconciliation.

A qualified accountant spent half the day retyping details out of PDFs, and that — not the difficulty of the accounting — was what capped the firm’s capacity. So the first loop was intake and posting, and reconciliation came only after it. The three months went mostly on the exchange with the accounting system and on the shapes of the source documents themselves: every client has their own.

Related

What this case is made of.

The service pages explain the method behind this project; the solution pages take the same building blocks on their own, each with its own scope and price.

Want the same for your process?

A free mini-audit projects the ROI for your highest-impact process — then the build is a fixed price.

Get a free mini-audit →