Examples / Accounting
Reconciliation
This is not AI that pays your bills. It reconciles the money across the tools you already use — then prepares four things a human approves: who to pay, what to refund, the apology emails, and the final report. It never moves a dollar and never sends a message.
Shown on a realistic sample month — real Stripe, bank, Ramp, Gusto and vendor-bill formats, an invented company (“Marigold Goods Co.”), no real financial data.
The leverage point
Reconciliation isn't one job, and the data lives in five places.
Every small business has a version of the same mess: a Stripe account, a bank feed, some card spend on Ramp or Brex, payroll in Gusto, a pile of vendor bills, and a spreadsheet of refunds owed. Closing the month means matching all of it, then acting on what you find — paying vendors, issuing refunds, apologizing to customers, and reporting the result. It's four jobs, not one, and no single platform sees the whole picture.
Most SMBs aren't on Ramp — and even on Ramp, not everything happens on Ramp. The information to reconcile already exists; it's just scattered across tools that don't talk to each other. That scatter is the leverage point.
So we don't replace your stack. We reconcile across it — whatever shape it's in — and hand the owner prepared actions to approve.
The build
Four outputs off one reconciled ledger. Every one stops at you.
Two of these move money and one touches a customer — so the human gate isn't a nicety, it's the entire product.
Pay-list
Builds the list of vendor bills to pay — who, how much, cited to the bill. Holds anything ambiguous so nothing is double-paid. Never pays.
Refunds owed
Flags every refund owed, cited to the order. Never issues one.
Apology emails
Drafts a cited apology per refund, ready to review. Never sends.
Final report
The reconciled statement: what matched, what's flagged, the month's position. Owner signs off.
How it runs
A short, inspectable chain — no black box.
Ingest with anchors
Pull Stripe payouts, the bank feed, Ramp spend, Gusto payroll, vendor bills, and refunds into plain rows — each tagged with where it came from, so every later match cites its sources.
Apply the business rules
The bank says ACH PINE SUPPLY; the vendor is Pinewood Supply. Vendor aliases, amount tolerance, and a date window live in one confirmed config — the "how this business works" layer a generic tool never has.
Reconcile, with a coverage gate
Match money-in against obligations-out. Every bank line is either matched or flagged — nothing is silently dropped. When two bills fit one payment, that's a question, not a guess.
Prepare the four outputs
Off the one ledger: the pay-list, the refunds, the apology emails, and the report — each cited back to source rows.
Stop at the human gate
Export everything for review. No payout is issued, no refund sent, no email delivered. The owner approves and acts.
The test it has to pass
We write the pass/fail bar before we build.
A reconciler that looks right on a clean month can quietly drop a transaction or double-pay a vendor on a messy one. So the value isn't the demo — it's the test set. The build ships only when all six bars are green on the sample data:
- Every matched pair cites both sources. A match you can't trace to two rows fails.
- Coverage gate. Every bank line is matched or flagged — a silently dropped transaction fails the whole run.
- Amounts reconcile within the agreed tolerance, or the difference becomes a question.
- Ambiguity is held, never guessed. Two identical vendor bills against one payment are held so nothing is double-paid.
- In-transit and unexplained items surface instead of being force-matched.
- The money boundary holds. Zero payouts, zero refunds, zero sends across the run. One breach fails the build.
The result
Measured, not promised.
This is a real runnable pipeline, not a mockup. The figures below are its actual output over the sample month, with a six-bar test set that has to stay green before it ships:
7 of 9 reconciled
Measured: seven bank lines matched to source; the other two flagged for review — none dropped. Coverage gate passes.
3 caught
Measured: an in-transit payout, a double-bill ambiguity held from payment, and an unexplained bank debit — all surfaced as questions, not guesses.
0 moved / sent
Measured across the run: zero payouts, zero refunds, zero emails. Enforced by the test suite.
Every figure here is produced by the build's own passing test set on the sample month. On your real books we'd measure the same way — reconciled rate, items caught, and the hours you get back at close.
Why this repeats
The same skeleton fits your workflow next.
Ingest-with-citations, apply-the-business-rules, reconcile-with-a-coverage-gate, prepare-cited-outputs, stop-at-the-human-gate is the same chain behind our quote drafter — and the one we point at invoice-approval chasing and support triage. Change the sources and the rules; the architecture holds. That's how a second build costs a fraction of the first — and why the example you're reading is also the starting point for yours.
Is close a scramble every month?
If reconciliation means chasing numbers across Stripe, the bank, Ramp, Gusto and a stack of bills, this build starts from here — pointed at your data instead of the sample. Tell us where close hurts.
Get in touch See other examples →