Azure AI Document Intelligence v2 Retirement: What It Means for Invoice, KYC, Contract, and Claims Automation

Azure AI Document Intelligence v2.0 API retired on August 31st 2026. If your invoice, KYC, contract, claims, purchase order, logistics, or HR document automation was built more than two years ago, there’s a reasonable chance part of that pipeline still depends on it, even if nobody on your current team knew it was there. 

That is the uncomfortable part of this retirement. It does not announce itself. A document workflow can keep producing correct results today while quietly running on an API version, SDK, or container that Microsoft will stop supporting. The failure doesn’t show up until the retirement date arrives, usually as a support call, a broken Power Automate flow, or a sudden spike in manual review. 

In this blog, we’ll break down exactly what’s retiring, what isn’t, which workflows are exposed, and what an enterprise IT or automation team should audit before the deadline. 

What Is Azure AI Document Intelligence?

Azure AI Document Intelligence is Microsoft’s cloud service for extracting structured data- text, tables, key-value pairs, and specific business fields- from documents such as invoices, receipts, ID cards, contracts, and forms. It combines OCR with machine learning models, offering both prebuilt models for common document types and custom models that organizations train on their own templates. 

The service was originally launched as Azure Form Recognizer. Microsoft renamed it Azure AI Document Intelligence as part of a broader rebrand of its cognitive services, but the underlying REST API, SDKs, and versioning scheme carried forward. This matters for this article because a large share of “Form Recognizer” deployments built between 2020 and 2022 are the exact implementations now approaching end of support.

What Exactly Is Being Retired on August 31, 2026?

Only the Document Intelligence v2.0 REST API is confirmed by Microsoft to retire on August 31, 2026.  Organizations still calling the v2.0 endpoint must move to a supported version; Microsoft’s official guidance points to v3.1 or later, before the data or calls will stop working.

This is a narrower scope than some secondary sources and internal notices suggest, so it’s worth being precise:

• v2.0 API:  retires August 31, 2026 (confirmed).
• v2.1 REST API: reaches end of support on September 15, 2027, not August 31, 2026. Microsoft’s Document Intelligence documentation lists this date separately from the v2.0 retirement.
• v3.0 REST API (2022-08-31): reaches end of support on March 30, 2029.
• Preview API versions (such as 2021-09-30-preview, 2022-01-30-preview, 2022-06-30-preview, and 2023-10-31-preview) are deprecated on a rolling basis as each corresponding GA version ships, on separate and typically much shorter timelines.
• v4.0 (2024-11-30) is the current generally available version and Microsoft’s recommended target for all new development and migrations.

If your internal planning documents or a vendor’s summary describe the v2.1 container or API as retiring on the same August 31, 2026 date as v2.0, that detail doesn’t match Microsoft’s current published documentation as of September 2026. The two versions are on different clocks. That’s a meaningful distinction for scheduling, but it isn’t a reason to wait; v2.0 is a hard stop in under a year, and v2.1 workloads sit on an architecture Microsoft has already flagged for retirement, just with more runway.

Why “retirement” is more than an API sunset

When Microsoft retires an API version, calls made against that version return an error rather than a result. For Document Intelligence specifically, this has already been observed in production: Microsoft’s support forums show organizations hitting an HTTP 410 “Gone” response with the message that the requested API version has been retired, once a version passes its end-of-support date. That’s the failure mode to plan for: not a gradual degradation, but a stopped process.

Custom models add another wrinkle. A custom model’s operational lifecycle is tied to the API version used to train it. Models trained against a preview API version, for example, are only supported for a defined window after the corresponding GA version ships and are not intended for continued production use once that GA version is available. The same logic extends to models built against v2.0 or v2.1; the model artifact itself, not just the calling code, needs to be assessed.

Why This Matters for Enterprise Document Automation

Most Document Intelligence deployments are not a single point of integration. A typical invoice or KYC pipeline chains together: a Document Intelligence resource and API version; a custom or prebuilt model; a Power Automate flow or Azure Function that calls it; validation and confidence-threshold logic; and a downstream system, Dynamics 365, an ERP, a claims platform, or a document management system, that consumes the extracted data.

An API version retirement breaks the chain at one link. Still, the business impact shows up several links downstream, often in a system or team that has no visibility into which Azure AI service version is running underneath. That is why retirement can look invisible at the process level until it isn’t.

Which Workflows Could Be Affected?

Invoice processing. Many accounts-payable automations built on the prebuilt invoice model or a custom invoice template were implemented while v2.0/v2.1 were current. Field extraction, PO matching, and approval routing logic downstream may assume a v2.x response shape.

KYC and customer onboarding. ID document extraction, proof-of-address parsing, and compliance-document workflows frequently used early custom models trained on regulator-specific templates. These models may need retraining, not just an endpoint change.

Contracts. Contract metadata extraction (parties, dates, renewal terms) often relies on custom template models that are among the most sensitive to version changes, since contract layouts vary widely and models are tightly tuned to specific formats.

Claims. Insurance claims processing pipelines that extract structured data from claim forms, medical bills, or accident reports typically combine custom models with multi-step validation logic, a good candidate for hidden dependencies.

Purchase orders and logistics. PO extraction and logistics document processing (bills of lading, packing lists) often integrate directly into ERP or transportation management systems, where a field-mapping mismatch after migration can halt downstream transactions rather than just flag an exception.

HR documents. Employee onboarding forms, ID verification, and tax document processing (e.g., prebuilt tax models) are lower-volume but often high-compliance-sensitivity workloads.

The Hidden Dependencies Organizations Need to Find

The core problem: an Azure resource showing “healthy” in the portal tells you nothing about which API version your application code is actually calling. The API version is typically set in application code, an SDK client configuration, a Power Automate HTTP action’s query string, or a custom connector definition, not in a setting visible from the Azure resource blade itself. This is precisely why teams can be confident their document automation is fine when it isn’t: the resource is up, but the calls it’s serving are on a version headed for retirement.

Three types of version references need to be separately checked, because they’re often mismatched:

1. API version: the literal api-version parameter in REST calls or SDK configuration.
2. SDK version: the client library version. Upgrading the SDK package does not automatically change the API version your code targets unless the code is updated to call the new methods and handle the new response format.
3. Model version: the version of the underlying model your custom model was built and trained against, which is separate from both of the above.

An organization can upgrade its SDK to the latest release and still be calling a retiring API version underneath, because the SDK upgrade and the application code change are two different tasks.

9 Things to Audit Before Migrating

1. API version

Search application code, Power Automate flow definitions, Logic Apps, and custom connectors for the literal API version string (e.g., api-version=2.0, 2023-07-31, 2024-11-30). Checking the Azure resource in the portal isn’t sufficient because the resource doesn’t expose which version each caller uses; that lives in the calling code and flow definitions.

2. Custom models

Inventory every custom model in production: how it was created (Document Intelligence Studio, REST API, or the Sample Labeling tool used with v2.1), which API version trained it, and whether it composes with other models. Because a model’s lifecycle is tied to its training API version, models trained on v2.0 or v2.1 should be evaluated for retraining against a current API version rather than assumed to keep working indefinitely.

3. Prebuilt models

For invoice, receipt, ID/KYC, contract, tax, layout, and general document extraction workloads, confirm which model version and API version each workflow calls, then validate extracted field names and structures against the target version; field-level output can differ between versions.

4. Power Automate flows

Identify every flow using the Azure AI Document Intelligence (formerly Form Recognizer) connector, an HTTP action calling the REST API directly, or a custom connector. Check trigger and action configurations, error-handling branches, retry logic, and approval steps; an API migration can change response field names or structure even when the flow’s visual design hasn’t changed, which silently breaks downstream parsing steps.

5. AI Builder components

Where AI Builder document-processing models are used (built on the same underlying service), confirm whether they were trained through AI Builder directly or imported as a Document Intelligence–trained model, since the two have different retraining paths.

6. Downstream validation rules

Review confidence-score thresholds, field-level validation logic, human-review triggers, exception handling, data normalization steps, and duplicate-detection logic. A model swap can shift confidence score distributions even when raw accuracy is comparable, which can silently increase or decrease how many documents route to manual review.

7. ERP and business-system integrations

Map how extracted data reaches Dynamics 365, ERP systems, SharePoint, document management systems, CRM platforms, finance systems, procurement systems, claims platforms, and HR systems. Field name or data type changes between API versions can cause integration failures that appear in the receiving system, not in Document Intelligence itself.

8. Test data

Build a representative test corpus: clean documents, poor-quality scans, multiple layouts and vendors, multiple languages where relevant, handwritten content where relevant, known edge cases, previously failed documents, and high-value or high-risk documents that carry outsized business consequences if misread.

9. Accuracy benchmarks and user acceptance testing

Establish a documented before-and-after baseline (detailed below), and route sign-off through the business teams who actually own the workflow outcome finance, operations, claims, KYC/compliance, procurement, or HR; not just the technical team running the migration.

How to Build a Safe Document Intelligence Migration Plan

A practical migration framework follows nine stages:

1. Discover: Inventory every Document Intelligence resource, API version, custom model, and calling application across the organization. Involved: Azure administrators, integration developers, Power Platform admins. Evidence: a version and dependency inventory spreadsheet. Risk: undocumented flows built by business users outside IT’s visibility.
2. Assess: Classify each workload by business criticality, volume, and complexity of custom models. Involved: solution architects, business process owners. Evidence: a prioritized risk register. Risk: underestimating low-volume but high-compliance workloads like KYC or tax documents.
3. Map dependencies: Trace each workload end-to-end: API call → model → flow → validation logic → downstream system. Involved: automation leads, ERP/CRM administrators. Evidence: a dependency map per workflow. Risk: stopping the trace at the Document Intelligence resource instead of following it into the business application.
4. Establish baseline: Capture current accuracy, confidence scores, exception rates, and processing times on the existing version before touching anything. Involved: automation leads, QA. Evidence: a documented baseline report per workflow. Risk: migrating first and trying to reconstruct a baseline afterward, which makes regressions impossible to prove.
5. Migrate. Update API version references, retrain or validate custom models, and update code or flow logic for response-format changes. Involved: developers, Power Platform admins. Evidence: updated code, flows, and model version records. Risk: assuming an SDK upgrade alone completes the migration.
6. Validate: Run the test corpus against the migrated pipeline and compare against baseline metrics field by field. Involved: QA, automation leads. Evidence: a side-by-side comparison report. Risk: validating only “typical” documents and missing edge cases that drove past exceptions.
7. UAT: Have the business owners of each workflow sign off using real operational scenarios. Involved: finance, operations, claims, compliance, procurement, or HR teams as relevant. Evidence: documented UAT sign-off. Risk: treating technical validation as a substitute for business validation.
8. Deploy: Roll out in stages, pilot workload, then broader deployment, rather than a single cutover across all workflows. Involved: IT operations, automation leads. Evidence: a phased rollout plan with rollback criteria. Risk: cutting over every workflow simultaneously with no fallback path.
9. Monitor: Track exception rates, confidence-score distributions, and processing times post-migration for a defined period. Involved: operations, automation leads. Evidence: post-migration monitoring dashboard or report. Risk: declaring success immediately after go-live without watching for drift over the following weeks.

Migration Impact Assessment Table

Component	What to check	Potential impact	Recommended action
API version	Literal api-version string in code, flows, connectors	Calls fail after retirement date (HTTP 410)	Inventory every caller; update to a currently supported version
Custom models	Training API version, model type, composition	Extraction accuracy drift; model unusable after retirement	Assess retraining need per model; validate against baseline
Power Automate	Connector actions, HTTP calls, trigger/error logic	Flows fail silently or route incorrectly	Audit every flow calling Document Intelligence directly or via connector
AI Builder	Model source (native vs. imported), retraining path	Document-processing models stop returning expected fields	Confirm training/import path; retrain if built on retiring API
SharePoint	Document library triggers, metadata mapping	Metadata fields populate incorrectly or not at all	Retest metadata extraction and mapping after migration
Dynamics/ERP	Field mapping, data types, integration middleware	Failed transactions, incorrect financial or operational data	Validate field-level mapping; test full transaction cycle
Validation rules	Confidence thresholds, exception logic	Review rates shift up or down unexpectedly	Re-tune thresholds against new confidence-score distribution
Test data	Corpus coverage of edge cases and known failures	Migration issues surface only in production	Build and retain a representative, reusable test corpus
Accuracy benchmarks	Field- and document-level accuracy, STP rate	No way to prove regression or improvement	Capture a documented baseline before migrating
UAT	Business-team sign-off by workflow owner	Technical success masking business-process failure	Route sign-off through finance, ops, claims, compliance, or HR

How to Measure Migration Success

Accuracy alone is an incomplete success metric. A migration should be measured against:

• Field-level accuracy: correctness of individual extracted fields, not just overall document classification.
• Document-level accuracy: whole-document extraction correctness.
• Confidence scores: distribution shifts that affect downstream routing, even when raw accuracy holds steady.
• Straight-through-processing (STP) rate: the share of documents that complete without manual intervention.
• Exception rate: how often documents route to manual review, and why.
• Human-review rate: reviewer workload before and after migration.
• Processing time: latency per document and per batch.
• Failure rate: outright processing failures, not just accuracy dips.

Comparing all eight against the pre-migration baseline, not just accuracy, is what separates a validated migration from one that “seems to work.”

Business Impact: From Technical Dependency to Business Consequence

To illustrate, as a hypothetical, not a reported case, consider an accounts-payable team whose invoice extraction flow depends on a custom model trained years ago against an early API version. If that model isn’t retrained or revalidated before the API it depends on is retired, extraction could fail outright or return incomplete fields. That technical failure could translate into unmatched purchase orders, delayed approvals, and ultimately late vendor payments a business consequence with financial and relationship costs, not just an IT ticket.

The same chain applies elsewhere: a KYC workflow that mishandles ID document extraction can delay customer onboarding and create compliance exposure. A claims workflow with degraded field extraction can produce processing errors that affect settlement timelines. A contract metadata pipeline that misreads renewal dates can create downstream legal or procurement risk. None of these are Microsoft’s fault or guaranteed; they’re plausible outcomes when technical dependencies aren’t audited before a retirement deadline, and they’re worth planning for rather than discovering after the fact.

What Enterprises Should Do Before the Retirement Deadline

With August 31, 2026 fixed for v2.0, and v2.1 workloads on a defined but shorter runway than many teams assume, the practical priority order is:

1. Confirm which API version every production workload actually calls; not just which resource it uses.
2. Treat any workload still on v2.0 as urgent, since that retirement is fixed and confirmed.
3. Treat v2.1 workloads as a near-term planning priority, given the shared underlying architecture and Microsoft’s clear recommendation to move to v4.0 for all new and existing development.
4. Build the dependency map and baseline before writing any migration code.
5. Get business-team sign-off, not just technical sign-off, before declaring the migration complete.

How Aufait Technologies Can Help

Aufait Technologies works with enterprise IT and automation teams on exactly this kind of cross-stack assessment, the kind that requires looking beyond a single Azure resource into the Power Automate flows, AI Builder components, SharePoint integrations, and ERP or Dynamics 365 connections that depend on it.

Where a partner adds the most value in a migration like this is in the parts that are easy to underestimate internally: building a complete dependency map across API calls, models, flows, and business systems; establishing an accuracy and confidence-score baseline before anything changes; assessing whether custom models need retraining versus straightforward reconfiguration; and coordinating UAT across the finance, compliance, claims, or procurement teams who ultimately have to sign off on the result. Aufait also supports the practical execution stages, migration testing, phased rollout, and post-migration monitoring, so issues surface in a controlled test cycle rather than in production.

If your organization has document automation running in production and isn’t fully certain which API version, model version, or container it depends on, that uncertainty is itself the first thing worth resolving, well ahead of August 31, 2026.

The August 31, 2026 retirement of the Document Intelligence v2.0 API is a specific, dated event, not a general call to modernize. But its real risk isn’t the date itself; it’s that the dependency often sits several layers below where anyone is currently looking, in a model, a flow, or an integration built years ago and left alone because it worked. Finding that dependency now, while there’s still runway to test and validate, is a considerably better position than finding it the week a workflow stops.

FAQs