Skip to content
Daniel Hang
All work

Fintech · Document AI

An AI accounting system that turns documents into closed books

How I built a multi-tenant accounting platform where an AI pipeline converts uploaded financial documents into structured records — accurate enough to post straight to the ledger, and fast enough to take most of the manual work out of month-end close.

Next.jsDjango RESTPostgreSQLDocument AIDockerAWS (ECS, RDS, S3)

Problem

Finance teams lose hours keying documents into their books by hand, and month-end closing drags because of it. As part of the engineering team, I helped build a multi-tenant platform that turns uploaded financial documents into structured accounting records automatically — accurate enough to trust, and fast enough to accelerate the close — with real-time reporting on top.

Constraints

  • Real-world financial documents are messy: scans, mixed layouts, missing fields.
  • Extraction has to be accurate enough to drive the books, not just assist.
  • Multi-tenant from day one — strict data isolation per customer.
  • Reporting needs to reflect new records in real time.

Architecture

01
Ingest
Document upload
02
Extract
AI pipeline → structured records
03
Validate
Rules + human review
04
Ledger
Accounting records
05
Real-time reporting
Dashboards
InfraNext.jsDjango RESTPostgreSQLDockerAWS ECSRDSS3
Uploaded documents run through an AI extraction pipeline, get validated before they touch the ledger, then feed real-time financial reporting.

Key decisions & tradeoffs

A pipeline tuned for accuracy, not just extraction

Getting reliable results on messy documents meant treating extraction as a pipeline — classification, field extraction, and confidence scoring — rather than one model call. Each stage is measurable, so I could see exactly where accuracy was leaking and fix it there.

A validation gate between the AI and the ledger

This output posts to the books, so a wrong number is expensive. I put a validation step — deterministic rules plus human review on low-confidence fields — between the model and the ledger, so nothing untrusted flows straight through.

Multi-tenant and configurable from day one

Every customer has its own data and its own rules. I built strict per-tenant isolation and a config-driven rules layer so customers adapt the system to their process without waiting on engineering — which keeps the codebase small as the customer list grows.

An interesting failure

My first extraction design broke on real documents

Early on, a single general-purpose extraction step looked great in demos and fell apart on the messy documents that turned up in practice. The fix wasn't a better prompt — it was structural: a staged pipeline, confidence scoring, and a validation gate. That's what got accuracy to a level the books could rely on.

What I'd carry forward

In accounting, accuracy and validation are the product — not the model. The staged pipeline and the validation gate are what made the automation trustworthy enough to actually close the books faster.