A scanned invoice can look perfectly legible to a person while remaining almost useless to a simple software parser. The supplier name may appear in a logo, the amount due may occupy the last row of a table, and a handwritten correction may sit in the margin. Ordinary text extraction can return the right characters in the wrong order. A downstream billing program, however, needs typed fields with evidence and a way to handle uncertain values. That is the practical problem addressed by Content Understanding.
An accounts-payable client needs supplier, invoice number, currency and total from a scan, but a plausible extracted amount is not always the amount due. Content Understanding should provide structured fields and evidence for validation before posting any payment. Microsoft AI-901 covers extraction from documents, images, audio and video. Microsoft’s current documentation distinguishes a production general-availability API from newer preview capabilities, so developers must choose an analyzer and experience appropriate to their required version.
Choose extraction instead of an unconstrained summary
Imagine an accounts-payable clerk who uploads a supplier invoice and wants a queue entry containing supplier, invoice number, issue date, currency and total. A generative summary may describe the invoice in fluent prose, but it may omit a field or silently combine numbers from different sections. For software integration, explicit field names and types are more useful. An extraction solution should return a structured record plus enough source information for review, rather than guessing which sentences an accounting system will parse.
Define what is required and what may be absent. An invoice might lack a purchase order or display several tax lines. A field that cannot be identified should be marked unresolved; a value from one invoice must not be carried over from the previous upload. Content Understanding can produce structured fields from source media, but the application still needs to validate that each value belongs to the correct source region and record. The implementation challenge is deciding exactly how an extracted value earns the right to enter a business workflow.
Understand the role of the analyzer
In Azure Content Understanding, an analyzer specifies the content type and processing behavior, including extraction options, model configuration and, for structured outputs, a field schema. Prebuilt analyzers support common scenarios, and custom analyzers can be created for a defined business record. The analyzer is a reusable processing contract, not a promise that all invoices have the same layout or that every number can be interpreted without ambiguity.
Microsoft’s analyzer reference describes base document, image, audio and video analyzers, along with specialized patterns such as invoice and document search. Supported details differ by analyzer and API version. Before building the client, verify the specific prebuilt or custom analyzer needed for the input. Do not copy an option marked preview into a GA example and assume it behaves identically. A fundamentals implementation benefits from stable capabilities and an understandable schema more than experimental feature coverage.
Design a field schema for downstream use
An invoice schema might specify supplierName as text, invoiceDate as a date-like value, invoiceTotal as a number, and a collection of line items with descriptions and amounts. Include currency explicitly rather than assuming a billing system can infer it from punctuation. Distinguish gross total from subtotal and tax. Those are business decisions, and a perfectly accurate OCR transcript cannot resolve a poorly defined accounting schema.
Schema names should be stable enough for a downstream integration to validate. A client should not send an unlabeled value directly into a ledger merely because the model returned a number with high apparent confidence. Validate basic types and relationships—for example, line amounts plus tax should reasonably reconcile with the stated total, allowing for rounding rules. If the numbers do not reconcile, route the invoice to review and preserve the original document instead of silently adjusting one field.
Layout and provenance are part of correctness
A complex invoice may have nested tables, columns, checkboxes or handwritten annotations. Document analysis can capture printed or handwritten text and layout information; structured extraction then uses that representation to fill fields. The reading order and page location matter. If a rate appears beside one item while the parser associates it with the next item, the resulting field can be grammatically clean but financially wrong.
Keep source context such as page, region or available evidence references when supported. A reviewer should be able to inspect the place where a suspicious amount originated. That is also useful when the vendor changes its template: an error report can identify which section broke, rather than merely saying the AI produced a wrong number. This makes the extraction service a diagnosable part of the application, not an opaque document-to-JSON box.
Make the client handle asynchronous processing
Document processing may involve an operation that runs beyond the initial request. The application should submit the permitted file, retain an operation identifier, then obtain the completed result through the supported client or REST pattern. Do not display a provisional extraction as final if the job has not reached a completed state. Timeouts, invalid file types, size limits and unsupported content need user-facing error outcomes with a reasonable path to retry or manual entry.
For an initial exercise, build a simple state machine: upload accepted, analysis pending, review ready, confirmed and rejected. A failed operation should not create an invoice record with blank totals. Protect retry behavior so a transient timeout does not start several duplicates of the same invoice review job. The application can compare a document hash or business identifier before initiating a fresh request, provided doing so fits its privacy and retention rules.
Use confidence and verification according to consequence
Some analyzer outputs can include confidence estimates, but a score does not prove a field is correct. An unusual supplier template may produce systematically wrong values while still looking plausible. Define practical review thresholds, especially for money amounts, legal names and account identifiers. A low-impact document classification can tolerate more uncertainty than approving a real payment. The user interface should make exceptions visible rather than burying them behind a green success badge.
Use a small corpus of permissioned example invoices with known expected fields. Compare extraction precision by field and document layout. Include a rotated scan, an invoice with multiple currencies, a handwritten correction and one that deliberately lacks a total. Review false positives as carefully as missing values. Responsible AI test-case approach should test whether extraction errors cluster in specific document styles or language groups, not only the overall success rate.
Understand how images, audio and video differ
Content Understanding is broader than invoices. For images, a custom analyzer may identify objects or fields relevant to a specific process. Audio analysis can transcribe and structure spoken content; video can involve time-aligned speech, selected frames and scene information. These inputs need different evidence structures. A timestamp in a meeting recording serves a role similar to a page number in a document, but the application should not flatten everything into anonymous text and then discard where the information came from.
Suppose a training team wants searchable decisions from meeting recordings. An audio or video analyzer may provide transcript segments and extracted topics that can be indexed later. That is different from asking a text-only summarization model to invent a meeting recap based on a fragment. Models and workloads separate text, audio and image capabilities; provenance and stable output fields then make results usable in application code.
Protect documents and outputs throughout the workflow
An invoice may contain bank details, addresses and employee names. Restrict uploaded files, analysis results and logs by the same business permissions that apply to the original record. Avoid storing full document content in general debug telemetry and define how long temporary uploads remain available. Where supported, configure region and service boundaries to meet the organization’s needs. An extraction service should not become an unintended new location where sensitive data is freely searchable.
Keep model-generated fields separate from verified transaction state. An accounts-payable system can propose an invoice record for a clerk to inspect, but approval must still follow the business’s authorization rules. If a document contains text instructing the application to send payments to a different account, the analyzer’s output remains source data, not a new instruction with authority over the workflow. That trust boundary is important even in small AI-901 exercises.
Close with a reproducible field-level test
Run one normal invoice through the supported analyzer, display its structured result and inspect the source evidence. Repeat with a missing field and a conflicting total. Confirm that the application reports uncertainty, preserves the file context, validates the expected schema and does not commit unreviewed values. Document the analyzer configuration and test cases so a future change can be compared with the original result instead of declared successful merely because a JSON response arrived.
A Content Understanding exercise passes AI-901’s practical intent when the learner can choose an appropriate extraction capability, create or reuse an analyzer, interpret a typed result and build a small reviewable application around it. The model or service does the extraction; the developer still owns data quality, business validation, privacy, and the point at which a suggested field becomes a trusted operational record.