Why Azure Document Intelligence Fails Production Teams and What Enforceable Alternatives Look Like

Azure Document Intelligence puts production at risk because it requires polling, can fail silently, and makes accuracy claims that leave customers to pay for wrong values. For teams replacing Azure Document Intelligence or another document extraction service, the strongest alternative is not another accuracy promise but a service with field-level measurement, contractual remedies, and zero retention. Self-hosted extraction and vision-model pipelines can work, but neither holds anyone to that standard on its own.

Why Azure Document Intelligence's architecture creates problems that don't appear in demos

A demo uses small documents in small numbers and is easy to connect through Azure-native integration. In production, documents come in batches, requests overlap, and the work has to finish sooner. Azure Document Intelligence requires polling rather than providing a webhook or callback when processing finishes. Each submission therefore creates more work for the caller. The application must keep asking whether the document is ready, weighing how often to check against the risk of hitting rate limits.

That makes GET capacity a production constraint separate from submission capacity. The Standard tier has default transactions-per-second limits for both POST analysis requests and GET polling requests, and customers can ask to raise them through an Azure support request. Every document can require multiple GET calls to resolve. As a result, polling can become the bottleneck before the application strains its own throughput or CPU capacity. A batch that looks manageable by document count can exceed the practical per-region polling limit.

Splitting documents into chunks retains this dependency and adds page-offset tracking, result reassembly, and reconstruction of tables or paragraphs that cross chunk boundaries. Processing those chunks in parallel also means more polling. The application now has more operations to coordinate. This is an architectural constraint rather than simply a tuning problem, because changing the polling interval trades response time against request pressure without removing the need to poll.

What silent regional degradation looks like from inside a production system

Microsoft Q&A describes a production incident that began September 23, 2025, in a healthcare application that used the prebuilt-read model in West Europe. Documents that had processed in under one second began hanging indefinitely. The caller manually terminated requests after two or more minutes. The reported failure rate was 100%, covering every document and every attempt in that application. That describes only the affected workload within Azure’s customer base.

The API still returned HTTP 202 Accepted. That response acknowledged submission but gave no indication that processing would never complete. The failure was inside the polling phase, where the caller received neither a result nor an error message. Azure’s status page did not show that the service was failing. The application was unusable and customer operations had stopped, despite the apparently successful initial response.

Microsoft’s response on the thread described a known issue affecting multiple regions, said engineering was working on mitigation, and recommended failing over to East US 2. A team needs multi-region orchestration to turn a regional recommendation into a working recovery path, and Azure does not provide that out of the box. For a regulated workflow, the problem is not merely delay but a failure that remains invisible until someone notices that nothing has completed.

Microsoft's own known-issues list and what it means for field accuracy in production

Microsoft’s known-issues page, published June 2026, lists six model-accuracy issues that are still active and says each affects all models. These failures concern the extracted content. A completed request can therefore present a different production problem from a stalled one. The documented mitigations also show where the managed service ends and application engineering begins.

Table recognition illustrates that boundary. Issue 2006 describes failures when tables on one page have different orientations, because the pipeline applies one rotation angle to the page. The workaround requires splitting the page into separate images by orientation, submitting them independently, and reassembling the results. Issue 2005 concerns single-row tables that are not classified as tables. Their content may need to be recovered from paragraphs or key-value pairs, or reconstructed using bounding-region coordinates.

Other issues change how individual characters are interpreted. Issue 2004 covers confusion between 1/l and O/0 in identifiers where the surrounding text gives few clues to the right character, so natural-language heuristics help less. Issue 2003 extracts superscript characters as ordinary inline text, requiring comparison of adjacent bounding boxes to infer elevated baselines. Issue 2002 intermittently returns a dash as the digit 1. On a financial document, that can turn a null or zero marker into an apparent amount.

Microsoft explicitly states that custom model training does not resolve issues 2002, 2003, and 2006, because the relevant recognition or layout processing happens before training can address it. The recommended mitigations instead put preprocessing and post-processing into the customer’s pipeline. Regular expressions, positional rules, coordinate comparisons, and manual result assembly become maintained software.

Why wrong values are harder to catch than missing ones, and what that costs downstream

A required-field check can spot a value that is missing. A plausible wrong value is harder to isolate because Azure can return a status of succeeded for an extraction containing errors. That status establishes only that processing completed. If a wrong value also passes the confidence threshold, it may never go through the usual exception path.

Consider an accounts payable pipeline that sends invoice totals to an ERP without field-level validation. If a dash marking a null value is extracted as 1, the output looks like a valid amount. It can pass a numeric type check and a range check, and may reconcile against a line item. Nothing about those checks establishes what the page actually said. The scenario illustrates the consequence of a documented recognition bug.

A misread invoice number or PO number can prevent matching, with the discrepancy visible during reconciliation potentially weeks later. The extraction itself has already been marked successful. Finding the cause then requires tracing the downstream discrepancy back to the source document.

This risk is acute in accounts payable, mortgage lending, and healthcare, where reviewing every output would defeat the purpose of high-volume automation. An effective pipeline therefore needs to distinguish “processing finished” from “this value is safe to use.” Availability monitoring cannot make that distinction, and confidence without field-level validation can suppress the very review an error needs.

How API version retirement adds migration debt to existing accuracy and reliability problems

Microsoft set August 31, 2026, as the end-of-support date for the v2.0 cloud API and the v2.1 container, after which those services will no longer be available. The v2.1 REST API has support until September 15, 2027. The deployment type changes the deadline. An internal inventory that records only “v2.1” can therefore hide a container workload that needs attention earlier than its cloud counterpart.

The overlooked caller may not be the main application. A shell-based batch job, a connector that a vendor maintains, or a monitoring script can keep using an old API version without a clear warning showing up in normal workload monitoring. Container deployments need their own infrastructure inventory because application code may call an internal service name that does not show the image version. Searching repositories for cloud API calls will not find every container running on Kubernetes or a Docker host. Even a deployment template that is no longer used can cause trouble if disaster recovery would bring back a retired image.

Migration targets also depend on the model. The v4.0 container does not support every model available in the v2.1 container. ID Document, Receipt, and Invoice container workloads have v3.1 available as a place to move, but cannot move straight to v4.0 containers. This prevents a uniform version bump. Teams need to check each model before choosing where to move it.

Preview retirement adds another migration track. Microsoft’s migration guidance requires users of 2024-07-31-preview, 2024-02-29-preview, and 2023-10-31-preview to move to v4.0 GA, API version 2024-11-30. Custom models trained on preview versions should be retrained on GA, though many models already in use can keep working with a change to the API-version string. When models need retraining, more complex documents take more work to label and train on. Those costs sit on top of polling infrastructure and accuracy workarounds.

What an enforceable accuracy standard actually requires, versus what vendor accuracy claims provide

The lesson for procurement is to define accuracy at the point where a wrong value causes harm. A document-level score does not show whether an invoice total, PO number, or other decision-making field is correct. Even an aggregate field-accuracy score can hide uneven performance across fields. On a 20-field invoice, errors may cluster in some fields, and some wrong values may matter more than others. The contract needs a measurement that matches the workflow.

That measurement starts with ground truth from the customer’s documents. Extracted values must be compared with manually verified values from the full corpus or a statistically representative sample. The sample needs to reflect the customer’s layouts, scan quality, and edge cases. A vendor benchmark shows performance on the chosen test set.

If confidence scores have not been calibrated against how often values are correct, a high score can let a wrong field pass without human review. A lower score that sends the same field to a person may be operationally safer. Confidence needs to reliably separate correct outputs from errors on the actual workload.

An enforceable standard therefore has three properties. It measures accuracy per field, uses the customer’s corpus or a representative sample, and specifies a commercial consequence when the agreed standard is missed. That consequence can be a pricing credit, an SLA rebate, or a contractual right to exit. Without it, the customer still absorbs the cost of failed accuracy promises. A commitment becomes commercially meaningful when errors affect the vendor as well as the buyer.

Zero data retention complements that accuracy standard for regulated documents. Sensitive financial and personal information should be kept only until the processing transaction ends. SOC 2, ISO 27001, or HIPAA compliance inherited from a cloud provider’s perimeter does not establish that documents are deleted after extraction. Security certification and retention answer different questions. Keeping documents even for a short time leaves the customer with duties under GDPR to manage retention and erasure in third-party storage, while zero retention after processing keeps that exposure to a minimum.

What should production teams evaluate when replacing Azure Document Intelligence or Google Document AI?

Procurement first needs to establish whether the provider accepts commercial responsibility for incorrect extraction. Paying only for correctly extracted pages makes errors a revenue cost for the vendor rather than solely a correction cost for the customer. The definition of “correctly extracted” still needs the field-level measurement described above. This field-level definition gives buyers a way to compare accuracy commitments.

Self-hosted open-source pipelines can work for teams that have enough engineers to build and run them. Marker, Docling, and MinerU are components for PDF-to-structured-output extraction, while LayoutLMv3 handles layout understanding and Pixtral and Florence-2 support vision-based extraction. They do not arrive with accuracy SLAs, field-level confidence calibration, or human-in-the-loop validation. The team must build and maintain those capabilities, including the difficult cases that document variety exposes after testing.

LLM and vision-model pipelines offer another route, including general-purpose language models and multimodal APIs. They address some structural limitations but introduce hallucination risk on degraded or unfamiliar documents. A plausible invoice total generated from a 150 DPI scan with a corrupted layout can recreate the same downstream problem as an OCR misread. Running two independent models and returning NULL when they disagree can reduce that risk, but adds latency and cost without creating a contractual commitment. Model confidence reflects an internal probability distribution.

The closing evaluation should therefore ask any vendor to demonstrate its protections. Does it measure and report per-field accuracy against ground truth, and does a commercial SLA back that measurement? Is zero retention the default? Are confidence scores calibrated and traceable to the source document, and does continuous learning improve performance on the customer’s actual documents? Those answers distinguish a replacement that changes the production risk from one that merely changes the extraction engine.