Document Intelligence 4.0 Gave AI Builder Table Confidence Scores. Most Invoice Models Still Can’t Use Them.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

A Dynamics 365 Finance implementation team building an automated three-way match workflow ran into a strange gap last month. Their AI Builder model pulled line items off vendor invoices cleanly enough, quantities, unit prices, and extended amounts all landing in the right columns, but the confidence score field meant to flag shaky extractions for human review came back empty for every table row. The fields around the table had confidence values. The table itself did not. Nobody on the team had touched the model’s configuration since it went into production eight months earlier, so the assumption was a bug, or maybe a licensing issue. It was neither. It was a decision made on day one, buried in a dropdown most builders click past without a second thought: whether the model was trained as a Fixed Template document or a General document.

That distinction matters more than it used to, because AI Builder table confidence scores quietly became a real capability when Microsoft folded Azure AI Document Intelligence 4.0 into the document processing model, and that upgrade behaves differently depending on which training path a model took.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

What Document Intelligence 4.0 Actually Changed

Microsoft moved AI Builder’s document processing engine onto Azure AI Document Intelligence 4.0 in stages, with public preview starting December 12, 2024 and general availability landing April 30, 2025. For a lot of Dynamics 365 and Power Platform teams, that rollout came and went without much fanfare, since existing models kept working exactly as before. The upgrade wasn’t a forced migration. It was closer to a set of new tools sitting behind the same interface, available to anyone building or rebuilding a model from that point forward.

The practical additions are worth knowing because they change what’s realistic to automate. OCR accuracy improved, particularly on dense or low-quality scans, the kind that come off a fax gateway or a photographed receipt rather than a clean PDF. Layout detection got better at handling documents where content shifts position from one vendor to the next. Signatures became a taggable field type in their own right, not just background noise the model had to work around, which opens the door to processing signed contracts, lease agreements, and approval forms in ways the older engine handled poorly. And confidence scoring extended down to the table level: individual cells, not just whole fields, can now carry a numeric value a flow or canvas app can act on.

That last point is where the invoice team’s gap came from.

The Model Type Decision Behind AI Builder Table Confidence Scores

AI Builder’s document processing wizard offers three starting points: Fixed Template documents, General documents, and an option to extend the prebuilt Invoices model with custom fields. Fixed Template is built for layouts that don’t move, the same vendor sending the same invoice format every time, and it trains fast because the model only has to learn a small set of positions rather than reason about structure from scratch. General documents is built for the opposite case, varied formats, inconsistent layouts, documents that might come from dozens of different sources, and it trains more slowly because it has to learn structural patterns rather than fixed coordinates.

Here’s the part that doesn’t show up until you go looking for it: table and cell-level confidence scores are only available on models trained as General documents. A Fixed Template model can absolutely extract a table, and it can extract it accurately, but it will not return a confidence score for that table’s cells. Field-level confidence outside of tables works normally on both training types. It’s specifically the table data, line items, schedules, itemized charges, where the gap shows up.

For an accounts payable automation scenario built around Dynamics 365 Finance or Business Central, this is not a minor footnote. Line-item extraction is usually the whole point. A header field like vendor name or invoice total is easy to validate against a purchase order regardless of confidence scoring, but line-item quantities and unit prices are where a bad OCR read causes a real financial error, and they’re exactly the data a human-in-the-loop review queue needs a confidence threshold to triage. A team that chose Fixed Template because their vendor’s invoice format never changes gets faster training and solid extraction, but loses the one signal that would tell them which rows need a second look before they hit the general ledger.

Signatures Change What’s Worth Automating

The signature field type deserves its own mention because it shifts the category of documents worth running through AI Builder at all. Before Document Intelligence 4.0, a signed document was something the model either ignored or occasionally misread as stray marks corrupting a nearby field. Now a signature can be tagged, detected, and reported on as a discrete extraction result, true or false, with its own bounding box.

That matters for scenarios well outside invoice processing. A Project Operations team processing subcontractor agreements can now confirm programmatically whether a returned PDF actually carries a signature before routing it into an approval flow, rather than relying on someone opening every file. A procurement team validating vendor onboarding paperwork gets the same benefit. It’s a narrow capability, but it removes a manual verification step that previously had no automated equivalent in AI Builder at all.

Abstract 3D grid of data cells representing table confidence scoring in AI Builder document processing

Migrating an Existing Model Without Starting Over

Teams running an older model built before the Document Intelligence 4.0 rollout are not required to rebuild from zero to get these capabilities, and the upgrade path is more forgiving than the version number might suggest. According to Microsoft’s own documentation, re-tagging every training document is only necessary if you’re adding new fields, checkboxes, tables, or signature detection that the original model didn’t have, or adding new documents to a collection. If the goal is simply to move an existing, working set of tagged fields onto the newer engine, editing and republishing the model carries the upgrade forward without forcing a full retagging pass.

That’s a lower bar than most people assume when they hear “new model version,” so the practical blocker for most teams isn’t technical effort. It’s the training-type decision made at the start, which can’t be changed after the fact. There’s no toggle that converts a Fixed Template model into a General documents model in place. If table confidence scores turn out to matter after production models are already live, the fix is a genuine rebuild, tagging documents again under the General documents path, not a settings change.

Getting Confidence Scores Into an Actual Review Workflow

Once a model is trained the right way, pulling confidence values into something a human reviewer or a flow can act on is straightforward. In a canvas app, a formula like First(FormProcessor1.Results.'Table 1').Amount.Confidence returns the score for a specific cell, and that value can drive conditional formatting, flag rows below a chosen threshold in red, or filter a gallery down to only the extractions that need eyes on them. In a cloud flow, the Extract Information from Documents action exposes the same values through dynamic content, which makes it possible to branch a flow so that high-confidence invoices post automatically while anything below the threshold routes to an approval step in Teams or a shared queue.

Setting that threshold is more art than science. Microsoft doesn’t publish a universal number, because the right cutoff depends on the cost of an error against the cost of unnecessary review. A finance team automating high-dollar vendor invoices will reasonably set a stricter threshold than a team processing low-value expense reports, and it’s worth running a batch of real historical documents through the Quick Test tool before committing to a number, since that’s where the actual confidence distribution for your document set becomes visible rather than theoretical.

Before You Build the Next One

The rebalancing lesson here isn’t that General documents is always the right choice. Fixed Template models train faster, tend to hit high accuracy sooner with fewer sample documents, and remain the right call for genuinely stable, single-format use cases where table validation isn’t part of the workflow. The mistake is making the training-type decision without knowing it also decides whether confidence scoring will be available on table data later, and finding that out only after a review process built around those scores comes up empty.

Anyone scoping a new document processing model, or auditing one already in production, should treat this as a five-minute check worth doing now rather than a surprise found in eight months. If line-item or table-level confidence scoring is part of the plan, even a future plan, General documents is the only path that supports it, and that has to be decided before the first sample document gets tagged.

At Routeget Technologies, this is the kind of gap we look for early in an automation build, not because the underlying capability is complicated, but because a wrong assumption made in a five-minute setup screen tends to surface eight months later, in production, exactly when it’s most expensive to fix.

#AIBuilder #DocumentIntelligence #InvoiceAutomation #AccountsPayableAutomation #PowerPlatform #EnterpriseAI

The AI Builder Copilot Credits Shift Is Rewriting Invoice Automation

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

A Dynamics 365 Finance and Operations customer running automated AP invoice capture on AI Builder’s invoice processing model will not notice anything different on November 2, 2026. The flow will still trigger, the fields will still extract, and finance will still get its exception queue for anything below the confidence threshold someone set two years ago. What changes on that date is not the model. It is whether the credits paying for every one of those extractions still exist, and for a lot of organizations that built this automation quietly, without anyone tracking which license line item was actually funding it, the honest answer right now is that nobody knows.

Microsoft has been unwinding AI Builder’s original credit system since November 2025, when it stopped selling new AI Builder capacity add-ons, and the second half of what amounts to an AI Builder Copilot Credits transition lands on November 1, 2026: every seeded AI Builder credit bundled into Power Apps Premium, Power Automate Premium, and Dynamics 365 Finance and Operations licenses gets removed on that date. Copilot Credits take over as the funding mechanism going forward, and Microsoft has been explicit on one point: there is no automatic conversion. Whatever balance an organization is sitting on today does not roll into a Copilot Credits balance tomorrow. It has to be purchased separately, allocated deliberately, or the automation simply stops running.

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

What Actually Sunsets, and What Doesn’t

It’s worth being precise about what this deadline touches, because the shorthand “AI Builder is going away” is wrong and it leads teams toward the wrong response. The invoice processing model, the document processing custom-model tooling, and the AI Builder connector actions inside Power Automate are not being retired. What’s ending is one specific funding source for them. Today, AI Builder actions in Power Apps and Power Automate draw first against AI Builder credits, whether that’s the 500 seeded into Power Apps Premium, the 5,000 in Power Automate Premium, or the 20,000 bundled into a Dynamics 365 Finance and Operations license, and only fall back to Copilot Credits once that pool is exhausted. After November 1, 2026, that first pool disappears entirely for anyone who hasn’t separately purchased an AI Builder capacity add-on before the cutoff, and Copilot Credits become the only meter running. Existing add-on holders get a longer runway, since those add-ons stay valid through their current contract terms even past the end-of-life date, but nobody can buy or renew one after November 1.

How the AI Builder Copilot Credits Rate Table Changes the Prebuilt-vs-Custom Decision

The part of this transition technical teams should actually care about isn’t the deadline itself, it’s the pricing structure underneath it, because it quietly resolves a tradeoff a lot of architects have been living with for years. Under the legacy AI Builder credit system, running a page through the prebuilt receipt or invoice model cost 32 credits, while running that same page through a custom-trained document processing model cost 100 credits, roughly three times as much. That gap pushed a lot of implementations toward the prebuilt invoice model even in cases where a custom model, trained on one vendor’s actual invoice layout, would have extracted fields more reliably. Under Copilot Credits, both capabilities are priced identically at 8 credits per page. The three-to-one penalty for training a custom model is gone.

That’s a real architectural decision point, not a footnote. If an AP automation pipeline has been leaning on the prebuilt invoice model and routing a meaningful share of extractions to manual review because one vendor’s layout doesn’t match the model’s expectations well, whether that’s multi-column line items, remittance details in an unusual spot, or a logo block that confuses the header fields, it’s worth revisiting whether a custom collection trained on that vendor’s actual documents would now clear review automatically instead. The cost argument that used to say no has mostly disappeared, and for high-volume vendors specifically, the accuracy gain from a purpose-trained model can be worth the labeling effort even before factoring in the credit parity.

Reconfiguring the Flow Itself

For teams staying on the prebuilt path, the “Extract information from invoices” action inside the AI Builder connector remains the fastest route to a working pipeline. It returns more than forty fields: invoice ID, vendor name, purchase order, subtotal, tax, and total among them, each in both a raw text form and a standardized number or date form. The standardized fields are the ones worth wiring into a Business Central or F&O AP posting call; the raw text versions exist mainly for audit trails and for surfacing to a human reviewer. Every field also carries its own confidence score between 0 and 1, and the model doesn’t enforce a threshold on your behalf, so that logic has to live in the flow itself. Anything below roughly 0.8 confidence, a starting point worth tuning against your own vendor mix rather than treating as gospel, should route to an approvals step instead of posting automatically. One configuration detail trips up new implementations more than any other: the page-range parameter needs to isolate exactly one invoice per extraction call. Feeding it a multi-invoice batch PDF and letting it run across every page returns fragmented, unusable data, so any intake process that scans a stack of invoices into a single file needs a splitting step before the AI Builder action ever runs.

Solution architect reviewing an automation pipeline diagram and scanned document previews on dual monitors

For teams building or reconsidering a custom document processing model given the new pricing, a few practical constraints are worth knowing before starting. Microsoft’s own guidance puts five documents as the technical minimum to train a collection, but fifteen to twenty is what actually produces usable accuracy, and that number climbs further when the source scans are lower quality. Each collection needs a single, consistent layout, which means a vendor sending three different invoice templates needs three separate collections rather than one, and a model can hold up to 200 collections, generous enough to cover a large and varied vendor base once the labeling work is done properly. High-volume AP operations should also plan around the platform’s processing ceiling of 360 documents per environment every 60 seconds; a month-end batch run that dumps thousands of invoices into a flow all at once will hit that limit and needs to be throttled or staggered rather than fired in a single burst.

Budgeting the Migration Before the Deadline

The practical work between now and November 1 starts with knowing what’s actually being consumed today. The AI Builder Consumption Report in the Power Platform admin center breaks usage down by environment, day, and user, and it’s the fastest way to find out whether a given AP automation flow is currently riding on seeded Dynamics 365 credits, a Power Automate Premium allocation, or an add-on nobody quite remembers purchasing. That figure, recalculated against Copilot Credit rates rather than legacy AI Builder credit rates, is the real basis for a Copilot Credits purchase, not a guess pulled from a vendor conversation. It’s also worth checking whether credits have already been allocated to specific environments in the admin center, because once an environment has an allocation, it only draws against that allocation. There’s no automatic fallback to a tenant-wide pool if it runs dry, which means a production AP flow deserves its own guaranteed allocation rather than sharing an unassigned pool with every sandbox and test environment in the tenant.

The failure mode is also worth testing deliberately rather than discovering it in production. When both AI Builder and Copilot Credits are exhausted, the action doesn’t degrade gracefully; it returns an EntitlementNotAvailable or QuotaExceeded error and the flow run fails outright. For an AP pipeline finance depends on to keep invoices moving, that’s a materially different failure than a low-confidence extraction routed to manual review. It’s a stalled queue with no automatic recovery path until someone notices and tops up credits. Building an explicit fallback now, an error-handling branch that logs the failure and alerts AP operations rather than letting the flow simply stop, is a small addition that avoids a genuinely disruptive incident in November.

None of this is a reason to walk away from AI Builder-based invoice automation, and the pricing shift actually opens up a better architecture for organizations that outgrew the prebuilt model years ago but never revisited the decision. It does mean the flows can’t keep running unattended the way they may have since they were first built. Anyone operating AP automation on this stack should treat the next several weeks as a genuine architecture review rather than a routine licensing renewal, and organizations that have worked through document capture pipelines like this with clients, Routeget Technologies among them, tend to find the credit math is rarely the hard part. It’s the vendor-layout audit and the fallback handling that actually takes the time.

#AIBuilder #CopilotCredits #PowerAutomate #InvoiceAutomation #DynamicsFinanceOps #EnterpriseAI