What Happens When the AI Reads an Invoice Wrong?
Every Invoice capture demo reaches the same moment. Someone in the room, usually the AP lead who will end up owning this, asks the only question they care about: what happens when it gets a number wrong?
Fair question, and the honest answer is that it will get numbers wrong sometimes. No extraction model reads every vendor layout perfectly. What matters is what the system does with the documents where it isn’t sure, and what catches the ones where it’s sure and still wrong.
The first gate: confidence scores, field by field
Invoice capture for Dynamics 365 Finance runs each document through an AI document extraction model, which returns the extracted value along with a confidence score for every field.
Those scores get checked against thresholds you define in the configuration group. A score below the threshold raises a warning or an error depending on how it’s configured. Errors hold the invoice for review. Everything that passes transfers to D365 F&O without anyone touching it.
The common mistake is setting one global threshold. A wrong vendor account sends money to the wrong company. A wrong line description costs nothing and is obvious to whoever reads the posting later.
Thresholds should be tiered by consequence: strict on vendor account, invoice number, total, currency and date, looser on descriptive fields where an error is visible and cheap to fix.
Confident and still wrong
A model can be wrong and confident at the same time, and it usually happens when a layout looks familiar. An invoice carrying both a gross and a net total in the spot where the total normally sits.
A credit note formatted like an invoice. A date the vendor wrote day-first that gets read month-first. Confidence describes how cleanly the document matched what the model expected to find, not whether the number is correct.
That’s why threshold tuning on its own isn’t the whole control.
The checks that catch confident errors are deterministic rather than statistical: total sales tax against the calculated tax, currency code against the vendor default, line quantities and units of measure against the purchase order, and the duplicate check on vendor plus invoice number.
These run after extraction and they don’t care how sure the model was.
What the reviewer actually sees
Held invoices open in the side-by-side viewer, document image on one side and extracted fields on the other, with the flagged fields marked. The clerk confirms or corrects, completes the review, and the invoice transfers.
The design goal is that the clerk verifies instead of re-keying. A review that requires reading the whole document is barely faster than manual entry. A review that surfaces three flagged fields and points at where they sit on the page takes seconds.
The part most teams assume wrong
Recognition quality is not fixed at go-live, and the improvement comes from several places rather than one.
Corrections made in the side-by-side viewer are captured as data: which field, what the model returned, what the clerk changed it to, for which vendor. That record is what tells you where the real problems are, and it feeds the work that follows.
For vendors whose layout the standard model reads badly, key-value pair mapping points the extraction at the right region of their document, so the next invoice from that vendor lands correctly.
Derivation rules cover legal entity and vendor account, which are the fields that decide whether an invoice can transfer at all. Thresholds themselves get adjusted per field once there’s enough history to justify the change.
And in those cases where a vendor’s document format is genuinely unusual and the volume of work justifies the cost, a dedicated document processing model can be trained for exactly those documents.
The pattern worth setting expectations around is that the gains are vendor by vendor rather than global. Your highest-volume suppliers are where the tuning pays back fastest.
Tuning it with numbers
Start strict. Then track two things per field and per vendor: how often a field gets flagged, and how often the flagged value turned out to be right anyway.
A field flagged constantly and corrected rarely means the threshold is too high, and you can lower it with evidence behind the decision. A field that passes silently and gets fixed later during matching, or by a vendor calling about a payment, means the threshold is too low.
Touchless rate is the number leadership will ask for. Correction rate by vendor is the number that tells you what to fix next.
The question worth asking at a demo
No extraction model is perfect, and any AP automation built on the assumption that one is will disappoint the team running it. What matters is everything sitting around the model.
Thresholds are set field by field, so the system won’t accept the values that carry real consequence on its own judgement. The validations run regardless of how confident the extraction was.
When an invoice does get held, the review screen lets a clerk settle it in seconds instead of reading the document from the top. And the mapping and training work keeps lifting recognition quality on the vendors you deal with most.
That’s also the thread running through everything we’ve covered on Invoice capture, from voiding and approval routing to three-way matching and line-heavy manufacturing invoices.
The automation is worth having because of how it handles the exceptions, not because the happy path is fast.
How One Lithuanian Turned Google and Facebook Into His Personal ATM for Two Years – and Why Your AP Team Could Be Next
No server breach. No malware. Just emails, letterheads, and a carefully chosen company name.
Over two years, two of the world’s largest tech corporations wired away $122 million – and every transfer looked entirely legitimate to their own finance systems.
Anatomy of the scheme
Lithuanian national Evaldas Rimasauskas didn’t breach Google’s or Facebook’s IT perimeter. He walked around it.
Step 1. He registered a company in Latvia called Quanta Computer – an exact namesake of the real Taiwanese hardware manufacturer both corporations already did business with.
Step 2. From 2013 to 2015, AP staff at both companies received targeted phishing emails from “managers” at their familiar supplier, complete with forged invoices, contracts, and company seals.
Step 3. The real trigger was a notice about changed banking details. That single step was enough: the money moved to accounts in Latvia, Cyprus, Hungary, and Hong Kong.
The outcome. Google wired roughly $23 million; Facebook, roughly $99 million. It took internal audit teams and the FBI until 2015-2017 to unravel the scheme. Rimasauskas was arrested in Lithuania and extradited to the US in 2017, and in 2019 he was sentenced to 5 years in prison along with forfeiture of nearly $50 million.
Why standard controls didn’t stop it
This wasn’t a story about careless employees. It was a story about process architecture.
- Vendor verification was a one-time event. A new or lookalike vendor passed checks once – and the system trusted it from then on.
- Bank detail changes were accepted on faith. A letter with a seal isn’t proof of identity – it’s just text.
- There was no purchase order matching. Large invoices weren’t checked against an actual PO; they were approved out of habit.
- Communication channels were never reconciled into one picture. Different emails, to different people, at different times – no one ever saw the full scheme at once.
If bank details in your company can change on the strength of an email from a “familiar” vendor, and invoice approval still runs on manual back-and-forth rather than systematic checks – you’re sitting in the exact same risk zone Google was in back in 2013.
How this gets closed architecturally – the D365 Invoice Capture example
Microsoft Dynamics 365 Invoice Capture, paired with Power Platform, turns invoice review from manual paper-reading into automated exception-based control.
- Fuzzy vendor matching. The system flags lookalikes such as “Quanta Computer, registered in Latvia” as early as document recognition – by name, tax ID, and legal address, not just text similarity.
- Centralized channel management. Every incoming invoice – from email, a shared mailbox, SharePoint, or OneDrive – lands not in scattered individual inboxes, but in one configurable intake channel. Each file is logged with its sender and automatically tied to the correct legal entity and access level. This directly closes the gap Rimasauskas’ scheme exploited: sending invoices through different channels and different people to fragment the picture no longer works, because everything converges into a single traceable stream.
- Three-way matching. Invoices are checked line by line against the purchase order and the goods receipt. No real PO, no automatic payment – no matter how convincing the seals look.
- Org structure driven by Entra ID. Invoice approval routing runs off the live hierarchy in Entra ID, not a static list of approvers. If the person who was supposed to sign off has left, been promoted, or has a different authority limit, the system automatically escalates up the chain – instead of getting stuck on an outdated route or routing “from memory” to the wrong person.
Legitimate invoices flow through automatically. Any deviation – an unfamiliar bank, a missing PO, mismatched details – halts the process and requires sign-off at the security level, not just from an AP clerk.
What to ask your team today
Three questions for your CFO, CISO, and head of AP:
- Can a vendor’s bank details change on the strength of an email alone?
- Is every large invoice checked against a real PO, or do some payments still move on trust?
- Does your invoice approval system know who actually holds sign-off authority today – or has the approver list gone stale since your last reorg?
If you’re not confident in the answer to even one of these – you don’t have a people problem.
You have an architecture problem.
Your Approver Just Left the Company. Does Your AP System Know?
Most AP approval workflows are built on a foundation that quietly rots. Someone sets up the approver list: invoices over $10k go to Sarah, invoices over $50k go to Michael. It works fine until the org chart moves.
Sarah gets promoted, Michael leaves, and a new director joins while nobody updates the routing. Invoices keep flowing into an approval chain that no longer matches reality.
This is what happens when your approval logic lives in configuration screens instead of where the actual org chart lives.
Where hardcoded invoice approval workflows fail
Promotions and role changes. Sarah was a manager with a $10k approval limit. Now she’s a director who can sign off on $50k, but the AP system still routes her the same invoices she used to see. The workflow doesn’t know her authority changed, so either payments go through the wrong person or IT gets a ticket.
Departures. The approver leaves and their account gets deactivated. Invoices start piling up in a queue nobody’s watching. By the time someone notices, you’ve got three weeks of stuck payments and a vendor calling about overdue invoices.
And even when everyone’s employed and in the right role, someone is always on vacation. If the workflow can’t handle delegation on its own, invoices sit for a week waiting for a signature that won’t come, and finance ends up running the manual escalation process that automation was supposed to eliminate.
None of this is unusual for an organization with more than 50 people. It’s Tuesday.
Invoice approvals driven by Microsoft Entra ID
The org chart already lives somewhere: Microsoft Entra ID (formerly Azure AD). Every time HR adds a new manager, updates a reporting relationship, or deactivates an account, that change flows into Entra ID automatically. Your AP workflow should pull from the same source.
Here’s how we built the logic on top of Invoice capture for Dynamics 365 Finance.
Step 1: Pull the hierarchy live. When an invoice arrives, Power Automate queries Entra ID to identify the requester and their current manager. There are no lookup tables to maintain; whatever Entra ID says today is what the workflow uses.
Step 2: Escalate by authority limit. Each role carries an approval limit, either set as a custom attribute in Entra ID or mapped to a role table in Dataverse. When an invoice exceeds the manager’s limit, the workflow recursively walks up the hierarchy (manager’s manager, then theirs) until it finds someone with sufficient authority. A $75k invoice doesn’t sit in a mid-level queue hoping someone figures out it should have gone higher.
Step 3: Handle delegation automatically. When an approver has their out-of-office set in Outlook, the workflow reads the delegate from Entra ID and routes the invoice there. Nobody sends “please approve this while I’m away” emails, and nothing waits in an unattended queue.
What this changes for finance and IT
The practical payoff is that nobody maintains approver lists anymore. The workflow reflects whatever HR has already done in Entra ID – one less system to keep in sync, zero IT tickets when roles change.
It also means compliance by default. Every invoice gets approved by someone who currently has the authority, not someone who used to. If a $100k invoice tries to route to a manager with a $20k limit, it escalates automatically, so nothing gets approved outside policy and patched up after the fact.
Stuck invoices stop being a category of problem altogether, because departures, vacations and reorgs no longer create bottlenecks. The workflow adapts as the org changes.
Under the hood
The implementation uses standard Power Platform components.
Power Automate handles the orchestration. The Office 365 Users connector pulls manager relationships and user attributes directly from Entra ID at runtime, not from a synced copy that might be stale.
Approval limits live in Dataverse, mapped to Entra ID roles or groups. When the workflow needs to know whether someone can sign off on a $40k invoice, it reads the limit from their current assignment.
For matrix structures, where an invoice needs both a line manager and a project owner to approve, the workflow runs parallel approval paths with dependency logic. Both must approve before the invoice posts.
Delegation uses the built-in Entra ID delegation attributes plus Outlook’s automatic replies. If either is set, the workflow respects it.
The org chart is already a source of truth
Every company maintains its hierarchy somewhere, whether that’s an HR system, Entra ID or Workday. The problem starts when that source of truth doesn’t reach your financial workflows.
Hardcoded approvers in an AP system are a small copy of the org chart that starts drifting the day it’s created. Dynamic approvals pull from the real one – you digitize the approval policy once, and it keeps itself current.
Beyond the Happy Path: Why Your AP Automation Needs Managed Voiding
Most AP automation tools are built for the happy path. An invoice arrives, the system recognizes it, matches it against the purchase order, and payment goes out.
But anyone who has run a finance department knows that a meaningful share of invoices should never reach payment. The amount is wrong, or the vendor submitted the same invoice twice, or the services were never delivered in the first place. These invoices need to be rejected, and this is exactly where most standard systems fall apart.
The “Just Delete It” Problem
Here is what typically happens when an invoice needs to be rejected: someone deletes the record. Maybe they send the vendor a quick email about it. Often they don’t.
Over time this creates real operational damage.
The first problem is missing context. The system never captures why the invoice was rejected. Six months later an auditor asks about it, and nobody remembers whether it was a pricing error, a duplicate, or something worse.
The second is vendor blindness. Your accountant removes the invoice from D365 F&O, but the supplier is still expecting payment. Reminders start coming in, and an AP clerk ends up digging through old email threads to reconstruct what happened. With dozens of vendors a month, this quietly eats the productivity gains your automation was supposed to deliver.
And then there is the duplicate that sneaks back in. Without a permanent “Voided” marker in the system, the same invoice can re-enter through a different channel, say a rescan or a slightly altered resubmission, and this time it gets paid.
Organizations processing hundreds or thousands of invoices a month run into all of this constantly.
What Managed Voiding Looks Like
We built a governed voiding process on top of Invoice capture for Dynamics 365 Finance that treats cancellation with the same rigor as an approval workflow.
When an operator clicks “Void,” the system first enforces a reason. Custom UI validation requires the user to select a justification such as “Duplicate” or “Services Not Rendered,” or to type a free-form explanation, before the void can be processed. This single step closes the audit gap most AP departments quietly live with.
Once the void is confirmed, a Power Automate flow sends the supplier a templated email with the exact reason for the rejection. The vendor can correct and resubmit right away instead of waiting weeks and wondering why payment is late.
The record itself is archived rather than deleted. It stays in Dataverse with a “Voided” status, fully visible for audits and reporting, but blocked from posting to the ledger or entering the payment queue.
Why This Matters to Finance Leaders
Preventing double payments is the most direct win. When a new invoice arrives, the system cross-references it against both active and voided invoices, and a matching vendor, amount, and invoice number gets flagged before a human ever touches it.
There is also a relationship effect that is easy to underestimate. Suppliers who receive instant, clear feedback on rejected invoices fix issues faster and trust your process more. Silence followed by a tense phone call three weeks later does the opposite, and it slows down your procurement cycle along the way.
And when auditors come, every voided invoice carries a complete trail: who voided it, when, for what reason, and what notification went to the vendor.
Under the Hood
The architecture stays entirely inside your existing Microsoft ecosystem. Power Automate handles vendor notifications, triggering on a Dataverse status change and pulling the rejection reason together with the vendor contact. JavaScript on the model-driven app form enforces the reason requirement at the UI level, so users cannot bypass it. Exclusion logic in the data pipeline filters voided records out of the export queue to D365 F&O, which removes the risk of a voided invoice ever reaching the general ledger.
No third-party software and no middleware. Everything runs on Power Platform and D365 F&O.
The Real Measure of AP Automation
Handling correct invoices well is table stakes. What separates a governed AP process from a merely fast one is how it behaves when an invoice is wrong. A system whose only answer to a bad invoice is deletion produces audit gaps at scale. Managed voiding turns those exceptions into a controlled workflow, with a documented reason and a permanent record behind every cancellation.