When AI fills six fields by resemblance, read them before you post

AP in Practice
Inferred AP coding can copy messy history. Why resemblance fills need labels, how explicit vendor rules differ from guesses, and what to ask before you trust auto-coding.

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 it does not. 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.

‍

The seafood team 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 top performing teams near 9 percent. 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.

‍

‍

Marking inferred fields so review knows where to look

Finofo marks inferred coding. When fields are decided by resemblance, the bill says 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. For the seafood team, that meant the messy invoice arrived with its tax lines coded, six of them marked as inferred, and the reviewer looked at those six rather than re-checking all eleven.
‍

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.

‍

This is what AI native means in practice, as opposed to AI added to older software. Finofo was built in Calgary from the first line of code around the idea that AP is verification, not data entry: the engine reads, codes and matches, and shows its work so the finance team can confirm rather than re-enter. Because accounts payable, expense management and purchasing share that one engine, the same markers appear on a texted receipt or a PO backed bill as on a vendor invoice, and the same memory improves all three. Finofo does the verification. Your team keeps the judgment.

‍

What stays with your team

Finofo is designed so that the people who sign off on the numbers stay in control of them. A few things are deliberately yours.

‍

The vendor master is the foundation. If the legal name, tax group and default GL are wrong in the master, resemblance has better wrong answers to copy. Finofo shows you which master fields drove a fill, so fixing the master or writing an explicit rule is a visible choice rather than a hunt.

‍

The first invoice from a new vendor is a guess by nature, and Finofo labels it as one. What turns the guess into a policy is your correction or your rule. Memory learns the right value from the bill you corrected, and the label is what tells you the learning has not happened yet.

‍

Review cadence is a decision you make with the evidence in front of you. Some teams want a higher auto post rate; Finofo's design choice is that a reviewer pausing on six marked fields is better than eleven silent ones, and it gives you the markers to set that threshold deliberately rather than by accident.

‍

‍

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 finance teams write themselves: 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 move. Guessy fields get eyes. Measure review minutes on marked fields, not total clicks. In Finofo, the marked subset is typically a handful of fields per bill, and the rest post without a pause.

Can we turn learning off for a vendor?

Ask any tool for a control that stops inheriting known bad history for that vendor while you rebuild rules. In Finofo, an explicit vendor rule takes precedence over resemblance for the fields it covers, so writing the rule is how you stop the model copying the past.

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 and Finofo shows you which one filled each field.

‍

‍

About Finofo

Finofo is the AI native platform built in Calgary for Canadian finance teams. It brings accounts payable, expense management and purchasing onto one engine, on the cards, bank and ERP a business already uses, with line level extraction, Canadian tax handling and approval workflows designed for multi entity, multi province operations. Finofo does the verification. Finance keeps the judgment.

‍

‍

‍

‍

Krishna Srikanthan
Head of Growth

Table of contents

How efficient is your finance team?

Thank you! Please check your inbox.
Something went wrong while submitting the form. Please retry

See Finofo in Action

Please wait. Redirecting...
Oops! Something went wrong while submitting the form.
Watch a demo