AI invoice reconciliation you can audit
Point a large language model at your AP inbox and it will reconcile invoices. It will also, some fraction of the time, match an invoice to the wrong PO, misread a quantity, or approve a price variance it should have flagged. When that happens, what you have is a transcript: pages of model output to scroll through, looking for the moment it went wrong. Nobody signs off on a month-end close backed by transcripts.
Pebble builds the process a different way. Invoice reconciliation becomes a verified environment: the process mapped into numbered steps, each step with its own verification check, run by an AI model inside that structure. The model does the work. The checks decide whether the work counts.
How does a verified environment reconcile invoices?
It walks numbered steps, and each step must pass a check before the run moves on. Here is a plausible step map for a three-way match process, with the check type at each step.
Step 1: Ingest the invoice, the purchase order, and the receiving document. The run pulls all three documents for the transaction. Check: computed. Code confirms three documents are present and that the PO number on the invoice resolves to a real PO in your system. No model grades this. Either the documents are there or they are not.
Step 2: Extract line items. The model reads the invoice and produces structured line items: SKU, description, quantity, unit price, tax, totals. Check: classified. A small model, trained for this one job and scored against held-out examples before it is trusted, catches illegible or ambiguous fields - a smudged quantity, a unit price that could be read two ways. A line item that fails the classifier does not flow silently into the match. It fails the step.
Step 3: Three-way match quantities and prices. The extracted invoice lines are compared against the PO lines and the receiving document: quantity billed against quantity ordered against quantity received, price billed against price agreed. Check: computed, the gold standard. Do the totals reconcile? Does the billed quantity match the received quantity? This is arithmetic, verified by code, not by a model grading its own work.
Step 4: Flag and classify discrepancies. Where the match fails - short shipment, price variance, duplicate billing, freight charges not on the PO - the model classifies the discrepancy type. Check: classified, scored against held-out examples of correctly labeled discrepancies.
Step 5: Post or route for approval. Clean matches post. Discrepancies get a written resolution note and route to the right approver. Check: judged. Your AP operators annotate a few hundred pass/fail examples of what a good resolution note looks like, Pebble trains a judge on them, and reports judge-human agreement on held-outs. Where agreement is too low, a human stays in the check. The routing itself - did the exception land in the right queue - is computed.
What happens when a step fails?
The run stops at the failed step, gets fixed, and resumes at that step, not from scratch. If the classifier at step 2 flags an illegible quantity, the run halts there. A person reads the field, the value is corrected, and the run resumes at step 2. Steps 3 through 5 never saw bad data, because bad data never got past its check.
Compare that to the unverified version, where a misread quantity surfaces three days later as a mismatched GL entry and someone reconstructs the failure from a transcript. In a verified environment, when something goes wrong you get a step number, not a transcript to scroll through. "Run 4471 failed at step 3, quantity mismatch on line 2" is a sentence your AP lead can act on in a minute.
Every run's record - each step, each check result, each fix - is appended to a training set. That matters for what comes next.
What do you own afterward?
A dataset of your reconciliation runs, and eventually an open-source model post-trained on it that belongs to you. Every completed run is a worked example of your process done correctly, with verified checkpoints at every step. That is exactly the kind of data reinforcement learning with verifiable rewards needs.
The path runs in three stages. First the environment runs on a frontier model: working software, real invoices. Then it proves itself: a full audit trail, reliability as a percentage read off run history rather than a vendor's claim, postmortems that start from a step number. Then you own it: an open-source model post-trained on your run records, running your reconciliation at a fraction of frontier API cost per run, that no one can reprice or deprecate out from under you.
How does an engagement start?
With a scoping call, and if an environment is the wrong tool for your AP process, Pebble says so on the call. From there: about a week of discovery inside your systems under your access model - Pebble keeps the step map and none of your data - ending in a written proposal. Then the build, exercised against real runs before it is called done. Then it runs, on your infrastructure or Pebble's, with a retainer.
Invoice reconciliation is one process. The same structure applies wherever a model does work someone has to trust - see how it handles safety-report triage, claims processing, and the receivables side in order to cash.
Ready to see your reconciliation process as a step map? Book a scoping call: [email protected].