Skip to article
AI and Machine Learning Document Intelligence

Receipt model

The Document Intelligence receipt model is a prebuilt model that uses OCR and deep learning to analyze sales receipts and return structured fields such as merchant, transaction date, tax, total, and line-item details. It supports printed and handwritten receipts in varying formats and quality.

Source: Microsoft Learn - Receipt data extraction - Document Intelligence Reviewed 2026-05-21

Exam trap
Posting extracted receipt totals directly to finance systems without confidence checks, duplicate detection, or human exception review.
Production check
Show the Azure AI resource and confirm endpoint, region, SKU, and network posture match the application configuration.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
prebuilt receipt model, Document Intelligence receipt model, receipt data extraction, prebuilt-receipt
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-21
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

The receipt model is Azure AI Document Intelligence’s ready-made extractor for sales receipts. Instead of training a custom model from scratch, you send a receipt image or PDF and receive structured fields such as merchant name, date, subtotal, tax, total, and items. It is useful when teams need to process many receipt formats but do not want to build OCR, parsing, and field-matching logic themselves. The model still needs good workflow design: validation, exception handling, storage, privacy controls, and business rules for low-confidence fields.

Why it matters

The receipt model matters because receipt processing is deceptively expensive when handled manually. Small purchases, field expenses, reimbursements, and point-of-sale records create thousands of low-value documents that still require accurate totals, dates, merchants, and tax details. A prebuilt model can reduce manual keying, speed reimbursement, and standardize extraction across formats. The business value comes only when it is integrated with validation rules, exception queues, fraud checks, and downstream accounting systems. Teams must understand confidence scores and model limits so automation does not blindly post wrong totals. Used well, the receipt model shifts staff from typing data to reviewing exceptions.

Technical context

In Azure architecture, the receipt model sits in the Document Intelligence data plane of an Azure AI services or Document Intelligence resource. Applications call the prebuilt receipt model through REST APIs, SDKs, or Document Intelligence Studio, then store extracted fields in systems such as databases, Blob Storage, queues, or workflow platforms. It often appears in expense processing, reimbursement, tax, claims, and purchasing pipelines. Surrounding architecture includes identity, network access, document ingestion, confidence review, schema mapping, monitoring, and retention. The model extracts data; it does not approve spending or enforce policy by itself.

Exam context

Compare with

Read model Custom document model Invoice model

Where it is used

Where you see it

  1. Document Intelligence Studio shows the prebuilt receipt model when users test receipt images and inspect extracted merchant, date, total, tax, and line-item fields during workflow design.
  2. REST or SDK responses include analyzed document fields, confidence scores, spans, bounding regions, and operation IDs used by validation and review workflows for expense processing.
  3. Expense, procurement, or claims pipelines reference prebuilt-receipt in API calls, queue messages, diagnostic logs, and exception dashboards for low-confidence extraction and finance review decisions daily.

Common situations

  • Automate employee expense intake by extracting merchant, date, tax, total, and line items before human exception review.
  • Process field-service purchase receipts from mobile uploads without building custom OCR and parser logic.
  • Normalize receipts from many merchants into a finance database while preserving confidence scores for audit review.
  • Support tax or reimbursement workflows where receipt totals must be matched against card transactions or purchase orders.
  • Route unreadable, duplicate, or low-confidence receipts to review queues instead of slowing every submission manually.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Construction firm speeds field expense reimbursement Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A construction firm had hundreds of field supervisors submitting fuel, materials, and meal receipts from job sites. Manual keying delayed reimbursements and created frequent total-entry errors.

Goals
  • Reduce receipt data-entry time for field expense reports.
  • Match extracted totals against corporate card transactions.
  • Route low-confidence or policy-sensitive receipts to review.
  • Protect employee and merchant data during upload and processing.
Approach using Receipt model

The finance engineering team built a mobile upload workflow backed by Blob Storage, Queue Storage, and Azure AI Document Intelligence. When a supervisor uploaded a receipt, a queue-triggered function called the prebuilt receipt model and extracted merchant, date, tax, total, and line items. Business rules compared the total and date with card transaction feeds, then routed exceptions to a review dashboard. Original receipts were stored with lifecycle retention, while extracted JSON was stored separately for audit and reporting. The Document Intelligence resource used private networking, diagnostic settings, and Key Vault-managed secrets for the worker app. Low-confidence totals never posted automatically.

Potential outcomes
  • Average reimbursement cycle time fell from six business days to two.
  • Manual data-entry corrections dropped by 64 percent after card matching was added.
  • Reviewers focused on 18 percent of submissions instead of every receipt.
  • Private networking and retention policies satisfied the company’s internal privacy review.
What to learn

The receipt model creates value when extraction is paired with matching rules, exception routing, and careful handling of financial evidence.

Scenario 02 Nonprofit reconciles disaster-relief purchases faster Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A disaster-relief nonprofit needed to reconcile emergency supply purchases made by volunteers across temporary shelters. Receipts arrived as phone photos, often with inconsistent lighting and merchant formats.

Goals
  • Record relief purchases within twenty-four hours of submission.
  • Separate food, medical, and logistics expenses for donor reporting.
  • Avoid losing receipts when connectivity was unstable.
  • Keep manual review focused on unclear or high-value purchases.
Approach using Receipt model

The nonprofit created an offline-friendly upload app that queued receipt images until volunteers regained connectivity. Uploaded receipts landed in Blob Storage and triggered a workflow that called the prebuilt receipt model. Extracted merchant, date, total, and line-item text were mapped to donor-reporting categories by a rules service. Receipts over a threshold or with low-confidence totals moved to a human review queue in Power Apps. Azure Monitor dashboards tracked submissions by shelter, extraction failures, and review backlog. The team kept original images for the required grant period and deleted transient processing logs quickly to reduce privacy exposure.

Potential outcomes
  • Ninety-one percent of receipts were recorded within the twenty-four-hour target.
  • Finance staff reduced manual transcription hours by 38 percent during the response period.
  • High-value purchase review stayed intact while routine small receipts moved automatically.
  • Donor reporting categories were available two weeks earlier than in the previous emergency.
What to learn

A prebuilt receipt model can speed urgent financial operations when the workflow is resilient to poor images and intermittent connectivity.

Scenario 03 Travel platform audits merchant charges at scale Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A corporate travel platform wanted to compare uploaded hotel and taxi receipts against itinerary and payment data. The goal was faster audit sampling, not fully automated expense approval.

Goals
  • Extract receipt totals and dates from high-volume travel submissions.
  • Flag mismatches between receipts, card charges, and itinerary records.
  • Preserve evidence for auditors without storing unnecessary raw data.
  • Measure model confidence by merchant type and country.
Approach using Receipt model

The platform used the receipt model as an extraction stage in a broader audit pipeline. Receipts uploaded through the travel app were analyzed by Document Intelligence, then a matching service compared merchant, transaction date, tax, and total against card and itinerary records. Mismatches, unusually low confidence, and selected random samples went to auditors. The architecture stored original receipts in encrypted storage with retention policies and stored normalized extracted fields in a reporting database. Azure CLI inventory reports verified the Document Intelligence resource, private endpoint, and diagnostic settings for each region. Model confidence by merchant type was reviewed monthly to tune routing thresholds.

Potential outcomes
  • Automated matching cleared 73 percent of routine travel receipts without auditor touch.
  • Mismatch detection found duplicate reimbursements worth 2.8 percent of sampled spend.
  • Audit evidence retrieval time dropped from hours to minutes.
  • Monthly confidence reports identified two countries needing stricter review thresholds.
What to learn

Receipt extraction is not approval by itself; its strength is turning messy documents into auditable fields that business controls can evaluate.

Azure CLI

Use Azure CLI for the receipt model because the model call is only one part of the production pipeline. There is no everyday portal-only setting that proves the workflow is ready. CLI helps an engineer verify the Document Intelligence resource, region, SKU, endpoint, keys, network rules, diagnostic settings, and private endpoint posture before applications send receipts. It also supports scripted evidence for audits and environment comparison. For actual document analysis, az rest can test the prebuilt receipt endpoint, but production teams should usually call the model through SDKs or services. CLI is best for inventory, readiness, security, and repeatability. and audits.

Useful for

  • Inventory Document Intelligence or Azure AI services resources that host receipt-processing applications.
  • Verify endpoint, region, SKU, keys, network rules, and diagnostic settings before enabling receipt ingestion.
  • Use az rest in a controlled test to confirm the prebuilt receipt model endpoint responds as expected.
  • Export resource configuration for privacy, finance, or audit teams reviewing receipt-processing controls.
  • Compare dev, test, and production AI resource settings when receipt extraction behaves differently across environments.

Before you run a command

  • Confirm tenant, subscription, resource group, Azure AI resource name, endpoint, region, and API version used by the receipt workflow.
  • Avoid exposing keys in shell history; use managed identity or secure secret retrieval where application design supports it.
  • Check network restrictions, private endpoints, provider registration, and diagnostic-setting permissions before testing model calls.
  • Use sample receipts that are approved for testing and do not contain unnecessary personal or payment data.
  • Capture JSON output for endpoint, SKU, network, and diagnostic configuration rather than storing raw receipt content in evidence files.

What the output tells you

  • resource kind, location, and SKU confirm which Azure AI resource receives receipt analysis requests.
  • endpoint fields tell applications where to send Document Intelligence REST or SDK calls for the prebuilt receipt model.
  • network rule and private endpoint values explain whether clients, workflows, or test tools can reach the resource.
  • diagnostic settings show whether failures, latency, and usage evidence flow to the team’s monitoring workspace.
  • analysis responses show extracted fields and confidence, which operators use to route records to automation or review.

Mapped commands

Document Intelligence receipt readiness

adjacent 
az cognitiveservices account show --name <account-name> --resource-group <resource-group>
az cognitiveservices accountdiscoverAI and Machine Learning
read-only Microsoft Learn 
az cognitiveservices account keys list --name <account-name> --resource-group <resource-group>
az cognitiveservices account keysdiscoverAI and Machine Learning
sensitive-read Microsoft Learn 
az cognitiveservices account network-rule list --name <account-name> --resource-group <resource-group>
az cognitiveservices account network-rulediscoverAI and Machine Learning
read-only Microsoft Learn 
az monitor diagnostic-settings list --resource <document-intelligence-resource-id>
az monitor diagnostic-settingsdiscoverAI and Machine Learning
read-only Microsoft Learn 
az rest --method POST --url "https://<endpoint>/documentintelligence/documentModels/prebuilt-receipt:analyze?api-version=<api-version>"
az restoperateAI and Machine Learning
data-plane-test Microsoft Learn

Architecture context

A seasoned Azure architect places the receipt model inside an ingestion-and-review pipeline. The front end uploads documents to controlled storage, a queue or workflow triggers analysis, Document Intelligence extracts fields, and business rules decide whether the result can flow to an expense, tax, or procurement system. Low-confidence fields should go to human review, not straight to payment. Identity and data retention need equal attention because receipts can contain payment details, employee names, addresses, and merchant information. I normally design separate stages for upload, extraction, validation, approval, and archival so model output is useful without becoming an uncontrolled financial decision engine.

Security
Security impact is direct because receipts can contain personal information, payment hints, travel patterns, merchant data, and business spending details. Access to the Document Intelligence resource, storage containers, queues, and extracted data should be least-privilege and preferably managed through Microsoft Entra identities. Keys should be rotated or avoided where managed identity is possible. Private endpoints, network rules, encryption, and diagnostic access matter when receipts are sensitive. Logs should not store raw documents or full extracted payloads longer than required. The main risks are broad storage access, exposing service keys, retaining receipts forever, and letting unreviewed model output update financial systems.
Cost
Cost impact is direct through Document Intelligence transactions and indirect through storage, queues, workflow runs, review labor, logging, and downstream integrations. High-volume receipt ingestion can become expensive if duplicate documents are analyzed repeatedly or if failed workflows retry without limits. Retaining original images, extracted JSON, and logs indefinitely also adds cost. FinOps owners should track pages or transactions, duplicates, average document size, review rate, and cost per approved receipt. Cost control usually comes from deduplication, right-sized retention, batching where appropriate, clear retry limits, and routing obviously invalid documents away from analysis before paying for model calls. or chargeback reporting reviews.
Reliability
Reliability impact is indirect but important. The receipt model does not run the whole expense process, but the pipeline depending on it needs continuity, retries, idempotency, and exception handling. Document uploads can fail, analysis operations can time out, formats can confuse extraction, and downstream accounting systems can reject fields. Reliable design stores original documents, tracks operation IDs, records confidence, and uses queues so receipts are not lost during service or network issues. Human review paths protect business continuity when extraction quality drops. Teams should test duplicate submissions, partial failures, large batches, and regional outage procedures before removing manual processing capacity.
Performance
Performance impact appears in document turnaround time, not application server speed alone. Receipt size, image quality, page count, regional distance, queue depth, retry behavior, and downstream validation all affect how quickly a user receives reimbursement or a finance record is posted. The receipt model can remove manual latency, but only if the pipeline avoids bottlenecks after extraction. Operators should measure upload-to-result time, analysis latency, review backlog, and posting latency separately. Performance tuning may involve compressing images carefully, parallelizing safe workloads, using queues, rejecting unsupported files early, and keeping human exception queues small enough that automation still improves cycle time.
Operations
Operators manage receipt-model workflows by monitoring the Azure AI resource, request volume, latency, failures, confidence trends, queues, storage, and downstream posting results. They need runbooks for failed analysis operations, low-confidence spikes, endpoint key rotation, private endpoint issues, and schema changes in finance systems. Document Intelligence Studio can help test examples, while CLI checks the resource and diagnostic posture. Operational evidence should include how many receipts were processed, how many required review, how many failed, and why. Teams should also maintain sample sets for regression testing when application code, validation rules, or supported receipt formats change. after each production incident review.

Common mistakes

  • Posting extracted receipt totals directly to finance systems without confidence checks, duplicate detection, or human exception review.
  • Testing only clean sample receipts and ignoring crumpled, handwritten, faded, foreign-language, or multi-page real submissions.
  • Logging full receipt payloads and images in places that are not covered by privacy retention rules.
  • Leaving broad keys in application settings when managed identity, Key Vault, or tighter secret handling is required.
  • Blaming the model for failed processing when the actual issue is upload format, queue backlog, endpoint networking, or downstream mapping.