Finance & insurance · case-study · Feb 2026

The invoice bot was sending SSNs to the model

An ordinary SAP invoice-extraction step was quietly passing two PII fields to the model. Here is what an Inspector caught in Watch mode, at zero risk.

Feb 20264 min readBy gopal joshi, Founder, Stringify AI

The workflow you already run#

A finance team automates invoice extraction: SAP hands a document to a model, the model returns structured line items, and the numbers flow on into the ledger. No one calls this "an AI project." It's just a step that got faster last quarter. That is exactly the kind of place AI actually lives in an enterprise — inside an ordinary workflow no one flagged for review.

The risk you can't yet see#

Look closely at what leaves the building. In the raw invoice payload sit a supplier contact's Social Security number and a date of birth — fields no one intended to send to a model, travelling out with everything else. Nothing is obviously broken. The line items come back fine. But if an auditor asked "what personal data reached the model, and can you prove none of it left your tenant?" the honest answer today is a shrug.

Why nobody misconfigured anything#

The Social Security number was not attached to the invoice by mistake. It sits in the supplier record. The supplier record joins to the invoice. The extraction step sends the payload it is handed. Every component did exactly what it was designed to do.

That is the pattern worth holding on to. Enterprise AI exposure is rarely a bug. It is usually a field that was always there, now reaching a system that did not exist when the schema was written. Nobody decided to send personal data to a model. Somebody decided, years earlier, to keep it next to the payment terms.

This is also why access reviews miss it. A review asks who is allowed to read the table. It does not ask what happens when a new consumer starts reading the same table for a different reason.

What a wrong one costs here#

Invoice extraction runs at volume, and that changes the arithmetic. A wrong line item does not stop. It posts to the ledger, joins a payment run, and turns up weeks later in a reconciliation — if someone is reconciling at that level of detail at all.

So the question is not how accurate the extraction is. It is what happens to a wrong one. Who sees it, how long it takes them, and whether the fix is a correction or a restatement. A team that can answer that has a system. A team that cannot has a fast step and a hope.

The personal-data exposure and the accuracy question are the same question, asked twice. Both come down to whether anything was written down.

The smallest version that produces a number#

Six weeks, one document type, one entity. Not the whole accounts-payable estate — a single invoice format from a single supplier group, which is enough to hit real volume and small enough that someone can still read a sample by hand.

Run the extraction as it runs today. Watch it. At the end you have three numbers you did not have before: how often a field was wrong, how many payloads carried personal data nobody intended to send, and how long a wrong line item survived before anything noticed it.

That last number is the one that decides whether to go further. If wrong items are caught the same day by a control that already exists, the exposure is smaller than it looked. If they are caught at quarter end, or not at all, you have found the actual problem — and it was never the model.

What an Inspector caught#

Started in Watch mode, an Inspector sat in front of the same call and observed — touching nothing, changing nothing, just recording what it would have done:

an inspector · watch mode SAP · invoice extraction
inboundextract invoice · SAP → model
filter · piiSSN, DOB scrubbed · pre-model
reconstructdates normalized · ISO
detect1 policy mismatch · flagged
output12 line items · schema-valid

On record#

Two PII fields it would have scrubbed before the model ever saw them. Dates it would have normalized. One policy mismatch it would have flagged for a human. All of it signed and on record, on the team's own stack — with nothing actually run. That's the whole idea of Watch: prove the value and see the exposure first, before you hand an Inspector any control.

None of that required a change to SAP, a new pipeline, or a decision from anyone about autonomy. The extraction ran exactly as it runs every day. The only difference is that afterwards there was something to read.

That is the argument for watching before trusting. Not that the model is dangerous, but that a workflow nobody can describe cannot be governed, improved, or defended — and you cannot describe it from the outside.

What to check in your own stack#

Four questions. None of them needs a tool to answer, and all four are worth asking before you buy one.

  • What is in the payload, not what is in the prompt? The prompt is written by a person and reviewed. The payload is assembled by a query and never read by anyone.
  • Who would notice a wrong one, and when? Name the person and the moment. If you cannot, the review path does not exist yet.
  • Where does the model run, and what leaves the tenant? "In our cloud" and "in our tenant" are different sentences.
  • What record survives the conversation? If the answer is application logs, the answer is no.

What this does not tell you#

An Inspector in Watch mode reports what it would have caught. It does not tell you whether the workflow was worth automating, and it does not find a rule you have not written. Your policy is the ceiling.

It also will not fix data it cannot reach. If the access is not there, Watch mode says so in week one — an uncomfortable finding rather than a deliverable, and better in week one than month nine.

← All insights