Case study

Automating 70 to 90 Percent of Bookkeeping End to End, at Half a Cent per Transaction

Outcome

70 to 90% of transactions automated end to end, 1,000+ per day

Client

AI-native accounting platform serving small and medium businesses (name withheld)

Industry

Fintech, SME accounting

Status

In production

My role

Architecture and implementation lead

Published

September 2, 2026

The client is not named under contractual confidentiality. Where this write-up says "we", it refers to the delivery team I led; the architecture decisions described are mine.

Context

Small and medium business finance teams spend a large share of every month matching bank transactions to invoices and bills, categorizing them, and producing the journal entries that feed reporting, tax filings, and audits. The work does not scale with transaction volume, and it introduces human error directly into financial records that are expensive to correct later.

The client is an AI-native accounting platform. The goal was not a bookkeeping assistant that suggests matches for a human to confirm. It was a system that takes a transaction from ingestion all the way to a posted accounting entry, on its own, for as large a share of transactions as it can do safely, and escalates the rest.

The Problem

Three things make this harder than it sounds. Matching is ambiguous: payer names are truncated or misspelled, amounts are split or bundled, and cross-currency payments do not match their invoices to the cent. Categorization is wide: more than 140 expense categories, with conventions that differ from one business to the next. And the output is consequential: a posted journal entry is a financial record, so a wrong entry is worse than a missing one.

On top of that, the platform serves many businesses at once, each with its own rules, such as always treating payments from a particular vendor a certain way. Encoding those rules by retraining a model per customer was never going to be viable.

Architecture

The core is a multi-step agentic pipeline built on LangGraph, structured as six coordinated processing nodes.

Matching. Incoming bank transactions are matched against open invoices and bills using a hybrid retrieval approach that combines vector similarity, meaning-based semantic matching, and counterparty identity signals. The three ranked lists are fused with Reciprocal Rank Fusion so that no single method dominates the decision. Cross-currency transactions are converted and matched automatically. When the fused signals agree, confidence is high and the pipeline proceeds; when they disagree, that disagreement routes the transaction to a human check.

Categorization. Every transaction is categorized across more than 140 expense categories by a three-stage pipeline: rule-based enrichment, an LLM classifier, and an LLM sanity-check pass that exists specifically to catch the classifier’s confident mistakes. Whenever a user corrects a categorization, the correction is captured and shapes future decisions without retraining anything.

Posting. The system generates the actual accounting journal entries for more than 12 transaction scenarios, including invoices, bills, payments, refunds, write-offs, and credit notes. This uses a ReAct-style agent with a plugin architecture, so a new scenario type is a new plugin rather than a rewrite of the core. Every posted entry carries a full audit record.

Model layer. A multi-provider architecture routes requests across Azure OpenAI, OpenAI, Anthropic Claude, AWS Bedrock, and Google Gemini, selecting a provider per task on cost, latency, and quality, with automatic failover when one is unavailable.

Reliability. Writes go through a two-phase commit pattern so a process failure mid-write can never silently lose data. A fingerprinting layer deduplicates identical AI calls to control cost. Every transaction is observable in Langfuse with cost, latency, and accuracy tracked individually. And a business memory layer lets each client encode its own rules, injected dynamically at the point of decision, without any model retraining.

Results

The platform processes more than 1,000 transactions a day, live across more than 10 client businesses. Between 70 and 90 percent of transactions are fully automated end to end; the remainder are flagged for a quick human check rather than a full manual review. Average processing time is under 2 seconds per transaction, at roughly half a cent of AI usage cost each. Every one of those numbers is visible in real time rather than estimated after the fact.

What I Would Do Differently

I would size the human-check queue as a product feature from the start rather than treating it as the leftover. The transactions the system declines to automate are exactly the ones a finance team most needs help with, and the review interface for them was built later than it should have been. The pattern in the pipeline, act when confident and escalate with context when not, deserved the same design attention on the escalation side as on the automation side.

Why it transfers

The architecture, extract, match, classify, act or escalate, and keep an audit trail, generalizes to any process that matches messy real-world documents against structured records: procurement invoices to purchase orders, insurance claims to policies, payments to contracts.