Invoice AP Intelligence Blueprint on NVIDIA NIM
The most dangerous sentence in accounts payable is polite. It shows up inside an ordinary supplier email, sometimes tucked into the notes field of a genuine invoice: our bank account has changed, please remit future payments to the details below. Same tone, same channel as every legitimate message the AP inbox has ever received. And that channel is exactly the one you'd be automating.
So the design question for an AP agent was never "can a model read an invoice?" It can. The question is what the model is never allowed to touch. Our answer is now open source: the Invoice/AP blueprint on GitHub, built on NVIDIA NIM with Nemotron models doing the reading and the drafting. It does the intake work end to end, from scanning the document to a drafted AP packet and supplier letter. And then it stops. A named finance approver decides. The agent has no path to payment, and that absence is the feature everything else hangs off.
One invoice, start to finish
A supplier invoice arrives as a scan plus an email. The order of the steps is the first design decision worth stealing. Screening runs before any reading or drafting, because supplier text is untrusted input: sentences written to hijack the system, or carrying a bank-change request, are withheld before any model reads them, and bank details in flagged text are masked out so account numbers can't leak into anything the model sees or writes.
Then the reading starts. The document is turned into text, and a separate check answers a dumber question: is this an invoice at all, and can anyone actually read it? One of our sample invoices is a poor scan, and the correct outcome for it is to say so. A person asks the supplier for a legible copy instead of the machine squinting harder. What can be read is pulled out field by field: supplier, dates, amounts, line items. Each value carries a note of how sure the reading is.
After that comes the step we refused to give the model.
The match is arithmetic, so the model never does it
A three-way match compares every invoice line against the purchase order and the goods receipt: quantities billed versus ordered versus received, unit prices, tax, totals, currency. The allowances are small, fixed, and written into the AP policy — the same for every supplier, every time. A supplier whose unit price has crept up over the purchase order gets flagged as a price discrepancy, every time, by the same rule. Handing that arithmetic to a language model would mean getting a worse answer, and occasionally a different one.
After the match is computed, nothing downstream gets to invent its own version. Fixed rules read it first and land on one of eight outcomes: a clean match, a price discrepancy, a quantity discrepancy, a missing purchase order, a missing goods receipt, a suspected duplicate, an unreadable document, or not an invoice at all. When a model is connected, it classifies independently from the same facts, and a written policy settles disagreements: agreement stands, confident rules beat a disagreeing model, a weak rule yields to a confident model. Both verdicts stay on the record. "The AI said so" is not an audit trail.
Diagnosis is the one step where the agent gets to be an agent. It looks up what it needs (the AP policy, the match results, the supplier's history, the purchase order), keeps the lookups few, then writes up what it found and proposes a shortlist of next steps. Fixed rules score and rank the list, and a fraud flag removes the approve option from it outright. Early-payment terms get priced the same careful way. On an invoice offering a discount for paying early, "2/10 net 30", the saving is weighed against the cost of paying early before any number reaches the packet.
The fraud screen is the product
Payment-diversion fraud arrives through the inbox, so an AP agent that transcribes supplier text is an attack surface with good intentions. We treat the defense as layers, each one assuming the previous one missed something.
The screen flags the bank-change pattern and blocks the case. The flagged sentences are stripped out of everything the model reads or drafts. The case file carries a plain label — bank-change request detected — never the sentence itself. And if bank content survives into a draft anyway, a hard check rejects the draft: account numbers, sort codes, IBANs, the words "new bank account", any of it.
There's a second check that does quieter work. The bank identifiers a document states get compared against the supplier master record: the details AP verified out of band, through a channel that isn't email. A mismatch is itself a fraud signal. A match is evidence the other way: one of our samples states the bank details already on file in its notes, and the screen downgrades what would otherwise be a pattern hit. Changing the master record is governed too. One operator proposes, a different operator approves with the out-of-band verification reference recorded, and the change applies only from its effective date. A document can never update the record it's checked against.
What happened when we ran it live on NIM
Without a model connected, the blueprint runs on fixed templates: the workflow works, but that is plumbing, not model behavior. So we ran it live on NVIDIA's hosted NIM service, with Nemotron models doing the reasoning, the document reading, the search across policy, and the visual checks. The document reading came back clean.
Then the model wrote its drafts, and the spine earned its keep. The AP packet carried none of the policies the diagnosis had cited, so the independent reviewer (a separate pass that didn't write the draft) blocked it. The supplier letter never stated its next step as a findable line, a repair attempt couldn't fix it, and the run sat at the approver's gate with nothing approved, nothing sent, nothing paid. That's the outcome we wanted from a bad drafting day: the failure landed on the draft, not on the company.
The live runs kept teaching. A separate review pass, grading the drafts against the record, caught a supplier letter claiming an invoice was "received and matched" when the match had only partly agreed; quantities were short. The words sounded clerical and were simply false. That became a rule: a claim in a draft now has to trace to the computed result, the same way every figure in the letter has to trace to the match. The same review exposed a dumber bug of ours. A duplicate resend scored as a clean match because the duplicate check could be left out of the run. If nobody passed the earlier invoices to it, it never saw the duplicate. The check now sits on the path every invoice takes, working from the earlier invoices in the case. It cannot be skipped by going around it.
Portable on purpose
NVIDIA NIM is the headline deployment because the Nemotron family covers the whole shape of this problem from one service. But nothing in the design is welded to it. The same blueprint runs on Anthropic or OpenAI models, on NIM inside your own data centre, or on models running on a machine in the office. The guardrails, the match and the gate do not change, because none of that was ever the model's job.
The supporting systems are kept standard: one database holds the approvals, the case records and the policy library; documents sit in ordinary enterprise storage; there is nothing exotic to back up or keep alive. One database, one backup story.
How we check the work
The blueprint ships with its own test set: a fixed pack of sample invoices the whole workflow runs against, in order. Order matters, because the duplicate case only duplicates if the original was processed first. The pack includes the awkward ones: duplicates, credit notes, the poor scan. A second pack runs the same cases against a live model and grades the drafts, and it refuses to run without a real model connected rather than grade its own templates. None of this is a real-world accuracy claim. The policy set in the box is illustrative, and the packs exist to catch us breaking something. As the live runs showed, they do.
Where this stops
Honest limits. Everything in the repo is synthetic: no real supplier, invoice, or bank detail anywhere. The document-reading connection is built around how NVIDIA's service accepts documents today; a different reading service would connect differently, and that is the one joint in the design that moves. This is a reference prototype, not a production AP system: no connection into a real finance system beyond a worked posting example, no payment rails, no company sign-on. And models differ in drafting discipline in ways you'll only see live. Reasoning models also think before they answer, and a setup built for short answers can mistake that thinking for a failure. Nemotron wrote fluent drafts and dropped pieces the checks require, which is why the checks are fixed and the drafts are untrusted until they pass them.
If your AP team spends skilled hours re-keying invoices and eyeballing matches, the shape worth copying is the split: models read and write, code computes and polices, a human decides anything that moves money.
Bring us a problem. If it's document intake like this — or any workflow where an agent has to be useful without being trusted with the irreversible step — start with Trida AI's intake: a few questions, then talk with founders and experts from Trida AI.
Get the Code on GitHub : github.com/tridaai/blueprint-invoice-ap-intelligence