Inspiration
Small businesses and freelancers lose real money to billing mistakes nobody has time to catch - a duplicate charge buried in a statement, a rate that quietly drifted above what the contract says, a price increase nobody actually approved. Catching these requires manually cross-referencing invoices against contracts, line by line, which almost nobody has time to do. I wanted to build something that could do that reconciliation automatically - but I didn't want to build another AI tool that just flags everything and makes the user do the real work of sorting false positives from real problems. If it's going to accuse a vendor of overbilling, it needs to be right, and it needs to be able to prove it.
What it does
LedgerGuard takes an invoice, its contract, and any supporting documents (amendments, statements), and reconciles them. It finds duplicate charges, contract-rate violations, and unauthorized price hikes - and for every finding, it shows the exact evidence: the specific invoice line, the specific contract clause, the calculated dollar impact. Nothing is asserted without a citation.
Just as important as what it flags is what it doesn't flag. If a price increase has a signed amendment on file with the right effective date, LedgerGuard checks for that authorization and correctly clears it - showing its reasoning instead of just flagging every price change and leaving the user to sort it out.
For every confirmed discrepancy, it drafts a dispute email with the evidence built in, but it never sends anything - sending is always a manual, deliberate action outside the app. You can also export the full findings as a PDF, and watch the whole analysis happen live, stage by stage, instead of staring at a spinner.
How i built it
LedgerGuard is built on a three-layer architecture, separating what to do from how to decide from how to execute:
- Directives (
directives/) - plain-English SOPs defining each pipeline stage's goal, inputs, and edge cases - Orchestration (
backend/agents/) - six independent Layer 2 agents that make decisions: triage, pricing, duplicate, contract-drift, synthesis, and dispute drafting - Execution (
execution/) - deterministic Python scripts that do the actual work: PDF parsing, OCR, clause matching, and - critically - all dollar-amount math
That last separation is the core design decision: no agent ever computes a dollar amount. Every financial figure traces back to exactly one place, a rules engine using Decimal arithmetic, and every investigation agent just cites that stored value as provenance. This means the system's reasoning (which agent, why) and its arithmetic (how much) can never drift apart or contradict each other.
I built this iteratively with Codex and GPT-5.6, verifying every single stage against real, generated PDF test documents before moving to the next - ingestion, then normalization and clause-matching, then the rules engine, then each agent, then the API layer, then the frontend, then live progress tracking. Each stage was tested against its real predecessor's actual output, not a mock, before being trusted.
Challenges I ran into
Getting clause-matching right. Real invoices don't word things exactly like contracts do. I had to build fuzzy matching with an ambiguity threshold - anything under 0.85 similarity gets flagged for review instead of silently force-matched, so a vague match can never masquerade as a confident one.
Catching my own false positives. Early on, I only tested the positive case for contract drift - an unauthorized price change, correctly flagged. It wasn't until I deliberately built the negative case (an authorized change with a signed amendment) that I discovered normalization had no concept of amendments at all - it would have flagged every authorized price change as a violation. That test caught a real architectural gap before it shipped.
A duplicate-counting bug Codex caught during edge-case testing. When I asked it to test a group of three duplicate charges instead of the usual two, it found its own rules-engine logic would have double-counted the impact - $300 instead of the correct $200 - and fixed it before I ever saw the bug in output.
A self-answering test fixture. One synthetic bank statement I generated contained a sentence directly stating "this duplicates the earlier charge" - which meant the test wasn't actually testing detection, it was testing whether the system could read a sentence that gave away the answer. Removing that line and making the duplicate provable only from matching amount, date, and description was the fix.
Accomplishments that I am proud of
The system has been tested against its own failure modes, not just its happy path - corrupted PDFs, password-protected PDFs, tax and partial-payment line items, degraded OCR scans (correctly flagged for manual review at 0.39 confidence instead of guessing), and both directions of the contract-drift case. The one I'm most proud of: the same $30 price change is correctly confirmed as a violation with no amendment on file, and correctly dismissed with a signed amendment on file - same evidence pipeline, opposite verdicts, based entirely on what's actually provable.
What I have learned
The most reliable way to build a trustworthy multi-agent system was to make each agent's job small and verifiable, and to be at least as rigorous about testing the negative case (where the system should correctly do nothing) as the positive one. Nearly every real bug in this build was found by deliberately testing the case where the "obvious" AI behavior would have been wrong.
What's next for LedgerGuard
Batch processing for multiple invoices at once, persistent history across uploads, and expanding OCR handling to lower-quality real-world scans beyond what's currently tested.
Log in or sign up for Devpost to join the conversation.