How AIME Reads a Statement: From a Photograph to a Line-Item Ledger

Every fee audit starts with the same unglamorous problem: the document. A merchant services statement is not a data feed. It is a PDF built for a printer, sometimes a scan of that PDF, sometimes a photograph of the scan taken on a phone in a back office. The numbers are all there. They are just not in a form anything can add up.

Most of the cost of a traditional fee audit lives in that gap. A consultant spends the first day retyping. AIME spends the first minute on it, and this is what it is doing.

Step one: is there text in here at all?

The first question the agent asks a PDF is whether it carries a text layer. A statement exported directly from a processor's portal usually does: the characters are real characters, positioned on a page, and they can be read exactly, with no interpretation and no chance of a misread digit.

A large share of statements do not. Anything that has been through a fax, a copier or a scanner arrives as an image of a page with no text behind it. The failure mode here is the dangerous one: a text extractor run against a scan returns an empty string and reports success. Nothing errors. You get a clean, confident, completely empty answer.

Step two: reading the page as a picture

When there is no text layer, each page is rendered to an image and read visually. This matters more than it sounds, because the meaning of a statement line is often carried by its position rather than its words.

Bank and processor statements routinely encode a flag by column: a value sitting under "In Range" and the same value sitting under "Out Of Range" are different facts. Flatten the page to a string of text and that distinction is destroyed. Reading the page as a page preserves it.

Two practical constraints come out of this. Pages are read in parallel rather than in one enormous pass, because a single request carrying a dozen page images is slow enough to time out and gives the model no room to reason about any of them. And there is a page cap: past a certain length, a statement is almost always a transaction detail appendix rather than more fee lines, and reading 90 pages of settlement detail buys nothing.

Step three: turning lines into a ledger

Extraction produces a candidate ledger: a description, a volume or count, a rate, a per-item amount, and a total, for every line the statement charges. Then the arithmetic starts, because extraction is where errors enter and arithmetic is where they surface.

• Row self-reconciliation. Does volume times rate, plus count times per-item, equal the line total? A row that does not reconcile is a row where a digit was probably misread, and it gets flagged rather than quietly averaged into your effective rate.
• Statement reconciliation. Do the line totals sum to the statement total? A gap means a missed line, a duplicated line, or a category that was never captured.
• Category assignment. Each line is sorted into interchange pass-through, assessments, processor markup, equipment and software, compliance, or the residual bucket of fees that exist to exist. That last group has its own field guide.

The reconciliation checks are the reason a scanned statement can be trusted at all. A vision model reading a smudged 8 as a 3 is not a hypothetical, and no amount of prompting eliminates it. What eliminates the consequence is checking every row against the arithmetic the statement itself has to satisfy.

Step four: the number that matters

With a clean ledger, the effective rate falls out: total fees divided by total volume processed. It is one division problem, and it is the single most useful number on the page, which is why it gets a whole article. Every line is then benchmarked individually, which is a separate job with its own logic, covered in Inside the Benchmarking Engine.

What about spreadsheets, photos and everything else

Statements arrive in whatever shape the vendor sends them. Workbooks are parsed in the browser before anything is uploaded, so a 40-tab rate review does not have to be printed to PDF first. Photographs taken on a phone go down the same page-image path a scan does. Pasted text works. The format is deliberately not your problem, because in practice the format is the reason most businesses never audit anything.

Where a human still belongs

Scanned line items get flagged for review, and that is a deliberate product decision rather than a limitation being confessed. On a statement with a real text layer, extraction is exact. On a scan, it is very good and occasionally wrong, and the honest thing to do is to say which lines came from which. A savings report you can take to a vendor has to survive that vendor's own review, so every figure carries its source.

Frequently asked questions

Does AIME need access to my processor account?

No. There is no integration, no credential, no API connection to your vendor. The input is a document you already receive every month, which is also why the audit can start today rather than after a procurement cycle.

How long does a statement take?

A text-layer PDF is usually a matter of a minute or two. A long scan takes longer, because each page is being read as an image, and the connection is deliberately held open with progress rather than timing out silently.

What if the statement is unreadable?

Then it says so. The failure states are visible: an unreadable page is reported as unreadable, not averaged over. That is the whole difference between a tool you can act on and a number you have to take on faith.

Can I compare two months?

Yes, and it is one of the fastest ways to catch drift. Upload the same vendor's statements for different months and the comparison lines them up side by side, so a rate that moved shows up as a moved rate rather than as a slightly larger bill. That mechanic is the subject of Vendor Fee Creep.