Case study 07 · Lab · Automation

A real build, working end to end. No web app and no deployment: a tool you run against a ledger. It catches seeded and synthetic anomalies; not yet validated on a real accountant's messy ledger.

Every journal entry, cross-examined three ways.

Month-end close is where booking mistakes get caught, or don't. I built a detector that reads the general ledger and works it over in three layers: deterministic rules for what is provably wrong, Benford and round-number heuristics for what looks engineered, and per-client learned models for what is simply out of character. Wired to QuickBooks Online through a sandbox-tested OAuth integration.

Role
Solo · design and build
Domain
Accounting · month-end close QA
Core stack
Python · QuickBooks · ML
Status
Built · waiting on a real ledger
01

What it looks for

Six classes of mistakes, from arithmetic to patterns. Every flag knows which layer raised it.

How it shows in the books
What catches it
Unbalanced entry
In the booksDebits and credits don't meeta journal entry that doesn't sum to zero
Caught byLayer 1 · hard rulearithmetic, not opinion
Duplicate transaction
In the booksThe same entry, twicesame amount, date and counterparty
Caught byLayer 1 · hard ruleexact-match detection
Transfer booked as income
In the booksOwn money counted as revenuea move between own accounts booked as a sale
Caught byLayer 1 · hard ruleaccount-type logic
Engineered amounts
In the booksFirst digits drift off Benforddigit distribution unlike natural books
Caught byLayer 2 · heuristicscored as suspicion, not asserted
Round-number structuring
In the booksToo many suspiciously round sumsa pattern, not any single entry
Caught byLayer 2 · heuristicscreened across the whole ledger
Out of character
In the booksLegal on paper, odd for this clientnothing broken, just unlike their history
Caught byLayer 3 · learned modeltrained per client, on their own books
02

Three layers, three kinds of certainty

Verdicts of different strength. The output never passes a hunch off as a fact.

Layer 01 · Hard rules

Provably wrong.

Deterministic accounting rules: unbalanced journal entries, duplicate transactions, transfers booked as income. Every flag traces back to a rule you can read.

Layer 02 · Heuristics

Statistically suspicious.

Probabilistic screens: Benford's law on digit distributions and round-number structuring. Flags arrive scored as suspicion, not asserted as fact.

Layer 03 · Learned models

Not like this client.

Per-client models learn each client's own booking history. An amount that is routine for one business is an outlier for another.


03

Wired to real books

The most sensitive thing this tool holds: access to real books.

  • QuickBooks Online, by the bookAn OAuth 2.0 integration, exercised end to end against Intuit's sandbox environment.
  • Secrets encrypted at restOAuth tokens are stored AES-encrypted at rest: access to the books is the most sensitive thing this tool holds.
  • A standalone toolNo web app and no deployment: you run it against a ledger and get flags back.

04

What's proven, and what isn't

Numbers exactly as the test report prints them. Nothing rounded.

434
Tests passingthe whole detection suite, TDD
2
Skippeddeclared, not hidden
1
Known-failinga stale local CSV fixture, not a code regression
AES
Token encryptionOAuth secrets encrypted at rest
Proven
  • Every seeded anomaly class gets caught. The TDD suite plants imbalances, duplicates, transfers-as-income, Benford drift and round-number patterns in synthetic ledgers, and the detector finds them.
  • The QuickBooks OAuth flow works end to end against Intuit's sandbox environment.
  • Tokens are AES-encrypted at rest.
Not yet proven
  • Detection quality on real data. Synthetic anomalies are cleaner than a real accountant's messy ledger; until the detector has run on live books, precision there is an open question.
  • Production operation. Nothing is deployed and nothing runs unattended: a standalone tool, run by hand.
  • That 1 failing test. A stale local CSV fixture: known, tracked, not a code regression. Written down here instead of rounded away.

05

Under the hood

Tech stack
Python QuickBooks Online API OAuth 2.0 AES at rest Benford analysis Per-client ML
Working principles
  • Certainty carries a labelA hard-rule violation and a statistical hunch never look the same in the output. Every flag carries its layer and its reason.
  • Honest test math434 passing, 2 skipped, 1 known-failing from a stale CSV fixture. Reported exactly as printed, never rounded up.
  • Secrets treated as radioactiveOAuth tokens are AES-encrypted at rest, because access to the books is the most sensitive thing this tool holds.
  • Tests firstEvery detector class landed together with its tests: seeded anomalies in synthetic ledgers the code had to catch before it counted as done.
ledger-detector / one close check
Close check starts: pull the general ledger (QuickBooks sandbox)
Layer 1 · hard rulesimbalances, duplicates, transfers booked as income
Layer 2 · heuristicsBenford digit test · round-number screen
Layer 3 · learned modelsscored against this client's own history
Findings collectedevery flag carries its layer and its reason
Done · tokens stay AES-encrypted at rest

Does your month-end close still rely on tired eyes alone?

Three detection layers, a sandbox-tested QuickBooks integration, and a test suite that reports its own failing test. What it needs next is a real ledger. It could be yours.