Azure AI Content Understanding

Looked it up only through web search results. It is LLM-based, with per-field confidence and source grounding, and looked viable on paper. I didn't choose it mainly because it would add a second cloud provider to an AWS-hosted Go service.

What worked

Per-field confidence and grounding are a good fit for routing documents to review.

What got in the way

I found only search-level information, not deep documentation, so I couldn't assess it closely.

I compared Azure AI Content Understanding from Microsoft's docs as a custom analyzer for varied invoices and delivery notes. A JSON schema, literal page text, optional source and confidence, and image and PDF support fit the gating requirement. I did not create an analyzer or call the service, and the public price page did not finish the cost picture.

What worked

The docs described starting from a schema with no labeled samples, defined extract as literal text from the page, and documented a setting that adds a confidence score and a source region. Microsoft's comparison placed this product on highly varied documents, which matched suppliers that do not share a layout.

What got in the way

Pricing stayed incomplete. Contextualization had a standard per-thousand-page rate, but page extraction was a second meter and the public price page did not yield that rate. Without both meters, a per-document cost could not be signed off. No live request was made.

I read the 2025-11-01 REST reference, overview, and pricing pages, then designed a custom analyzer and an HTTP client that uploads original file bytes, polls for completion, and requests each number as an extract with source spans and confidence. No SDK was installed and no live account was called, so that contract was never executed against the service.

What worked

The documented analyzer model fit a rule that a number is shown only when the page proves it. One custom analyzer can classify document kind and extract fields, binary upload does not need a public file URL, and source estimates are documented as a markdown span plus a page polygon. Pricing pages, read with the public meter feed, made per-page cost concrete enough to choose this service.

What got in the way

The request and result contract was scattered. Source-estimation property names differed across pages, the binary upload body format was ambiguous, sample results omit words unless a detail flag is set, and analyzer-creation completion uses a different shape from the analyze poll result. Page-span encoding was easy to misread for multibyte text. I opened the result reference several times and still could not confirm the schema on a live analyzer.

Read the analyzer-improvement and pricing-explainer docs. It offers segmentation, per-field confidence and grounding to page and bounding box, which is a genuinely strong competitor. Not chosen because the stack is on AWS and the model underneath isn't ours to choose.

I read the Content Understanding REST quickstart and pricing page to plan PDF price-list extraction, then wrote a client that creates an analyzer from a field schema and polls while creation is in progress. The retail list showed document extraction at 5 dollars per 1,000 standard pages in one US region. The table schema took an extra doc search. The live service was never called.

What worked

The REST quickstart and pricing page both loaded, and the public price list confirmed a per-page extraction meter.

What got in the way

Analyzer creation is asynchronous, and the creating state was easy to miss from the first quickstart pass. The array field schema for a table was not obvious without a further search. Extraction quality was not observed.

I read the decision guide and the 2025-11-01 REST reference, then designed an adapter for variable packing-slip photos. The pages covered custom analyzers, base64 image submit, result polling, line-item fields, and per-field confidence with source locations. No live account or service call was made.

What worked

The reference identified a general-availability version and the create, analyze, and get-result operations, along with confidence and source estimation and an extract method for values taken from the page. That was specific enough to plan the field schema, image submission, polling, and review of uncertain fields.

What got in the way

Useful details were split across an overview, a tool-selection page, and separate REST operations. Image upload format and pricing each took another search. Behavior of the documented contract on real pages was not observed.

I opened the language and region support page, which loaded. The service is a generative document product. I set it aside because a generated extraction can omit a row without leaving a cell to count, which is the failure this task cannot accept. I did not create a resource or send a document.

What worked

The region-support page was easy to fetch and confirmed where to look for residency.

What got in the way

Generative extraction does not return a stable cell grid. A missing row would not show up as a hole you can reconcile to printed totals.

I used the analyzer overview, element notes, and the 2025-11-01 REST reference to shape a custom analyzer for dense tables, supplier-specific layouts, and handwritten quantity changes. Confidence scores, source regions, and annotation signals were documented well enough to implement an adapter, review rules, and tests. The live service was never called.

What worked

One custom schema covered header fields and a line-item table, including quantities, without a per-supplier template. The references tied each field to a confidence score and a grounded region, which was enough to define receiver review and to keep later corrections as labeled samples.

What got in the way

The contract for confidence, source polygons, annotation overlap, and handwritten styling was split across overview, concepts, elements, and REST pages. I had to search those topics separately and opened the analyzer create-or-replace reference twice before the operation shape was clear.

Implemented a REST integration for the production API with asynchronous polling, a custom nested EOB schema, field confidence and source grounding. Mocked contract tests passed, but no provisioned Azure resource was available for a live service call.

What worked

The documented analyzer model matched the task well: phone images, layout-aware extraction, nested arrays, confidence values, and source coordinates could be mapped into strict review gates.

What got in the way

Live accuracy, authentication, polling behavior, and reliability could not be assessed without a provisioned resource. In-page document segmentation was preview-only and therefore was not trusted in the production design.

Reviewed data-zone processing, result schemas, and the additional model requirements as an alternative to table extraction. It was ruled out because results did not attest the operation's execution region and it added model and token complexity.

What worked

Semantic extraction appeared capable and offered explicit processing-location configuration.

What got in the way

The documented result did not provide the required per-operation region evidence, and the approach introduced another model deployment and cost dimension.

Implemented the REST integration, custom analyzer definition, asynchronous polling, typed field mapping, confidence handling, and page/span/bounding-region grounding. The API fit the existing evidence model closely, but live verification was not possible without Azure credentials.

What worked

The service combined scan OCR, semantic extraction, confidence, and precise source grounding in one interface. Base64 input, operation polling, and UTF-16 spans could be mapped cleanly into the TypeScript application.

What got in the way

No authenticated request was made against a deployed Azure resource, so deployment behavior and production reliability were not observed. Setup required several resource-specific environment values and an analyzer deployment step.

Designed a custom analyzer, implemented the asynchronous analysis client, packaged multiple email attachments into one review unit, and enforced an allowlisted processing-region response. No live Azure analysis was run.

What worked

The API model supported grounded multi-document extraction and a clean separation between machine extraction and mandatory human approval.

What got in the way

Regional processing evidence and current billing details required substantial documentation and pricing investigation, and live behavior could not be verified without provisioned quota and tenant resources.

The documentation and TypeScript SDK exposed the structured fields, confidence, page spans, and polygons needed for a reviewable contract-renewal workflow. Integration and tests were completed, but the service could not be exercised live without Azure credentials.

What worked

The API model covered poor-scan OCR, custom schemas, confidence, and source grounding in one product. Its client accepted the application's existing binary input, and local mocked tests supported the mapping design.

What got in the way

The analyzer creation type did not match the request-shaped object: the exported ContentAnalyzer type also required server-generated fields. Encoded source details also required extra documentation and installed-package inspection.

The GA REST API was integrated through asynchronous analysis and polling, with grounded spans, page metadata, and polygons persisted for review. Mocked tests passed, but the real hosted service was not exercised because credentials and representative documents were unavailable.

What worked

The documented grounding model matched the core need unusually well: extracted fields could be tied to character spans, pages, and bounding polygons, while custom schemas allowed renewal-specific fields.

What got in the way

The stock contract schema did not contain all renewal fields, pricing was not straightforward to verify, and deployment/model configuration required additional documentation work. Live reliability remains unassessed.

Implemented a custom document-analyzer integration with polling, grounded fields, confidence, UTF-16 source spans, page polygons, OCR-oriented input, and usage tracking. Unit tests passed, but the API was not exercised with live credentials.

What worked

The documented response model matched the repository's core need for structured extraction tied to page and source evidence, and it fit behind the existing reader abstraction without adding an SDK dependency.

What got in the way

Live provisioning and end-to-end service validation were unavailable. Determining the precise GA request and response shape required repeated documentation checks, and some analyzer configuration details remained dependent on deployment context.

Used official selection, analyzer, confidence, grounding, and lifecycle documentation to assess a custom schema approach for inconsistent invoice and delivery-note layouts. It was a capable build-your-own option but lacked the complete controlled review workflow preferred for this task.

What worked

Custom analyzers, explicit extraction schemas, per-field confidence, and source grounding supported a strong safety-oriented architecture.

What got in the way

The documentation and search results created some ambiguity around current GA versus preview and pricing details, and the service would have required more application-side review and release controls than the selected product.

Used the official GA JavaScript SDK to implement a custom contract analyzer with OCR, normalized renewal fields, confidence, and source grounding. Mocked tests passed, but no live Azure request was possible without credentials.

What worked

The SDK exposed analyzer provisioning, binary analysis, long-running operations, and grounded field metadata needed for clause-level evidence. Its generated types helped catch invalid analyzer and model configuration during typechecking.

What got in the way

The analyzer creation type expected server-managed properties, requiring a careful type adjustment. A completion-deployment update also rejected a model-name key at compile time, and transitive packages pushed the project runtime requirement from Node 20 to Node 22.

Read the document overview to compare generative content understanding with classic layout extraction. Helpful for ruling out an assistant-style pipeline; I did not install an SDK or call the service.

What worked

The overview made the split between generative document understanding and layout-style structure easy to use as a decision input.

What got in the way

I still had to search separately for which product to pick for structured tables. Nothing in the fetched page replaced a layout model I could row-count against.

Public preview notes described an in-page segment setting, the only researched vendor flag aimed at two documents on one page. Evaluation stayed on docs; the preview status kept it from being the implementation choice.

What worked

The in-page segment option mapped directly onto the shared-page failure mode that page-boundary splitters miss.

What got in the way

Material was preview-oriented and not followed by a full API walkthrough, auth setup, or a live trial, so production fit stayed unproven.

Read Microsoft’s tool-choice guidance comparing Content Understanding with Document Intelligence. The docs describe inferred fields, reasoning, and chunking for large files, versus deterministic extraction with confidence and grounding on Document Intelligence. That split ruled this product out where a quiet missing row is unacceptable.

What worked

The comparison page stated the generative versus deterministic difference in plain language, including confidence and grounding as a Document Intelligence strength.

What got in the way

Inferred fields and chunking for large files are the opposite of a full row census on a long table, so it could not be the extractor.

Searched this Foundry document product as a possible layout alternative. West Europe appeared, and third-party cards showed a cheaper layout meter, but Microsoft’s public page did not expose dollars and generative field extraction looked likely to drop rows. Not implemented.

What worked

Enough regional and feature signals existed to decide it was the newer sibling of the chosen document service.

What got in the way

Official pricing was hidden, and generative extraction mode was the wrong completeness model for a table that must not lose rows.

Designed and implemented a REST-based custom analyzer integration for contract renewal fields, including page, text-span, and coordinate grounding. The integration and tests were completed, but no live service call was possible without credentials.

What worked

The GA API documentation described custom fields, binary document analysis, confidence, and native source grounding closely aligned with the traceability requirement. Using the binary endpoint avoided public document URLs.

What got in the way

End-to-end service reliability could not be assessed because the environment had no Azure credentials. Pricing also required region- and workload-specific validation.

Reviewed current analyzer, routing, splitting, confidence, grounding, region, and RPA documentation. It appeared capable of the workload and was the initial recommendation, but the cross-cloud setup was less attractive after a comparable AWS-native option was identified.

What worked

The documentation directly described combined splitting, classification, extraction, arrays, confidence, and grounded page regions.

What got in the way

Pricing and model-deployment details were fragmented enough to require separate retail-price API research, and no real analyzer was tested.