An AP lead at a seafood processor sat with us while messy vendor PDFs hit the screen. Invoices did not look alike. Some carried pages of non-invoice noise. The team already feared something quieter than a bad OCR read: if the system learns from everything a user once typed, messy history becomes the model.
The direct answer is this. When coding is filled because an invoice resembles earlier ones, the system should say so. A resemblance fill is a guess with a label. Read those fields before you post. Do not treat inferred GL and tax as if a human had authored a rule.
This matters most if your AP history is uneven, if vendors arrive under different layouts each month, and if you have already watched an automation tool copy last month's mistake with confidence.
The second problem after "AI will code it"
Most AP automation stories stop at capture accuracy. Read the total. Read the date. Suggest an account. Move on.
That works until the second problem appears. History based coding copies what was entered, not what was meant. If last period's clerk parked PST on the wrong account under deadline pressure, resemblance learns the park. The model becomes fluent at reproducing an error nobody has named yet.
Buyers said this out loud. Relying on everything a user puts in can be messy, and then it is not helpful for the machine. The fear is not that AI exists. The fear is that dirty history becomes policy without anyone noticing.
Complex logistics invoices make the issue sharper. Different tax rates on different lines, internal codes that only your team understands, and PDFs loaded with tables that are not the bill. Resemblance across vendors is a weak signal when the documents only look similar at a glance.
What the numbers put around the risk
Ardent Partners' Accounts Payable Metrics That Matter in 2025 reports an average invoice exception rate of 14 percent, with best-in-class near 9 percent (same report family as the $9.40 average cost and 32.6 percent touchless rate). Coding errors sit inside that exception pile. Touchless processing averages 32.6 percent. Inferred coding that nobody reviews is how invoices look touchless while still being wrong.
These are US-weighted industry figures. Use them as context for why silent automation is not free. Your own measure is simpler: how many posted bills needed a correcting journal the following month because GL or tax followed a lookalike instead of a rule.
A review test you can run on any AI coding tool
Ask the vendor, or ask your own workflow, these five questions before you trust a suggested code.
1. Can the system tell you which fields were filled by an explicit rule versus by resemblance to prior invoices?
2. After a human corrects a field, does the correction become memory you can inspect, or a black box weight?
3. What happens when historical coding for a vendor is known to be dirty? Can you stop learning from it?
4. Are tax treatments visible at line level, or only as a header guess?
5. Does the bill record show "worth a read" markers before posting, or only after an ERP reject?
If the answer to question 1 is no, you are buying confidence theatre. If the answer to question 3 is no, you will clean history forever inside the model.
What we built, and the decision underneath
We mark inferred coding. When fields are decided by resemblance, the bill should say so in plain language, in the spirit of "11 of 11 coded fields filled, 6 by resemblance, worth a read before posting." The point is not to scare the clerk. The point is to put attention on the guessy fields and leave rule driven fields alone.
Human edits become memory the team can see and adjust. Vendor-specific extraction rules sit beside that memory for policy that should never be inferred: anytime PST appears, code the balance to the product account; convert lines with an implied FX; remap a column that means something only for this vendor.
We rejected the design where AI coding is silent until something breaks in the ERP. By then the exception is political. We also rejected training-only stories that never show the clerk why a field filled. Transparency is a product surface, not a footnote in a security whitepaper.
Who this applies to
This matters most if your team posts from AI-suggested fields today and the residual risk is resemblance filling the wrong but plausible value.
Where this does not help
Transparency does not clean a dirty vendor master. If the legal name, tax group, and default GL are wrong in the master, resemblance has better wrong answers to copy. Fix the master, or author an explicit rule.
Memory still needs human corrections. A first invoice from a new vendor will guess. That is expected. What we refuse is pretending the guess was a policy.
Deliberate choice: we show the guess instead of hiding it to inflate a touchless metric. Some buyers want a higher auto-post rate and less friction. We would rather a reviewer pause on six resemblance fields than post eleven silent ones.
Back to the messy PDF
The seafood invoices will keep arriving looking unlike each other. That is not a failure of capture. That is the job. When six fields fill because they resemble something else, read them. Post the ones that earn it.
What "worth a read" should mean operationally
A label that fields were filled by resemblance is worthless if every field is labelled. Noise trains clerks to ignore warnings. The useful design marks the guessy subset and stays quiet on rule-backed and explicitly extracted fields.
Operationally, AP leads should define a posting rule: resemblance-marked tax and GL fields require a glance; resemblance-marked descriptions may not. Publish that rule so temporary staff do not invent their own.
Seafood and distribution buyers who fear dirty history are not anti-AI. They are anti-amnesia. They want the system to remember corrections, and they want to see when memory is guessing rather than knowing.
Pair transparency with authorable rules
Transparency alone still leaves policy unspecified. The stronger pattern is the one buyers co-author mid-demo: anytime PST appears, put it on the product account; convert lines with implied FX; ignore decorative columns. Rules carry intent. Resemblance carries correlation. A healthy bill record shows both, and makes the difference obvious.
A posting policy you can paste into Slack
Try this wording with your team for two weeks. "If the bill marks resemblance on GL or tax, glance those fields before post. If a vendor rule authored the field, trust it unless math fails. If you correct something, correct it in the bill so memory learns the right value." Then count how many correcting journals you cut next month. If the count does not move, the labels are decorative and the rules are missing.
Frequently asked questions
Does marking resemblance slow AP down?
It slows the wrong fields down. Rule backed fields should move. Guessy fields should get eyes. Measure review minutes on marked fields, not total clicks.
Can we turn learning off for a vendor?
Ask for a control that stops inheriting known-bad history for that vendor while you rebuild rules. If the product cannot answer, treat every suggestion as temporary.
Is resemblance the same as a vendor extraction rule?
No. A rule is an instruction you authored. Resemblance is pattern matching against prior bills. Both can fill a field. Only one is an explicit decision.
