-
-
Nine decisions in one run: auto-posts, safety holds, and an honest 5% confidence case instead of a guess.
-
Live production logs, the real GPT-5.6 calls happening in real time, not simulated.
-
Nine decisions in one run: auto-posts, safety holds, and an honest 5% confidence case instead of a guess.
-
All five agents complete on a timing-and-safety sample: post-dated checks, NSF returns, and duplicates.
-
Multi-entity sample: parent-payer and factoring relationships resolved directly in the ledger view.
Inspiration
Anyone who has worked in accounts receivable knows the pain of cash application. A payment lands in the bank with a truncated name, a factoring agent's name instead of the actual customer, or a remittance note that barely makes sense. Matching that payment to the right invoice takes real judgment, not just a lookup table, and most tools either force a human to do it by hand or force an automation to guess and hope. I wanted to build something that could actually reason through the ambiguity the way a person would, but never touch the money math itself.
What it does
Ledger Sense takes raw bank payments and an open accounts receivable ledger and reconciles them. It resolves who actually paid, even when the name is truncated, a DBA, an alias from an acquisition, or a factoring intermediary. It matches payments to invoices using deterministic code so every dollar is verified, never estimated by a model. When a case is genuinely ambiguous, GPT-5.6 reasons through it and either recommends posting or routes it to a human, with a plain-language explanation attached to every single decision. Every step is written to an audit log that cannot be edited or deleted.
How I built it
I used Codex from the ground up. Early on, I deliberately discarded a first implementation attempt after noticing it had drifted toward patterns from an earlier, unrelated project, and rebuilt the system independently using only the OpenAI API and GPT-5.6. From there I worked through the architecture piece by piece with Codex: a five-agent pipeline where deterministic code handles normalization, ledger indexing, matching math, and posting, while GPT-5.6 is reserved specifically for entity resolution and exception reasoning. I built the system against a list of 34 real-world AR edge cases across categories like amount mismatches, identity resolution, multi-entity relationships, timing issues, and compliance holds, and verified each one against real sample data.
Challenges I ran into
The most important one was a safety bug I found during testing. In one case, GPT-5.6 recommended auto-posting a transaction that had no verified invoice match at all. That should never happen in a financial system, so I traced the root cause, found that partial invoices were being excluded from matching and that nothing was stopping an unverified model recommendation from posting automatically, and fixed it by adding a hard rule in code that GPT-5.6 cannot cause a posting unless the match has been independently verified. I also hit a quieter bug where an empty environment variable was silently overriding a valid API key, which made the app look like it was working correctly when it was actually falling back to a safe default. Catching both of these gave me more confidence in the system than if everything had simply worked on the first try.
What I learned
Building this made clear how much of good AI system design is about deciding what the model should never be allowed to do, not just what it's good at. GPT-5.6 is genuinely strong at resolving ambiguous identities and reasoning through messy real-world cases, but the money math has to stay in code, with hard limits that a model cannot override no matter how confident it sounds. I also learned that the most valuable moments in the build were the ones where something broke in a way that revealed a real design flaw, because those are the fixes that actually make a financial tool trustworthy.
Log in or sign up for Devpost to join the conversation.