Investigation Request: Azure Document Intelligence Processed Pages Discrepancy – September 2026

Question

1. Issue Summary

We have identified a significant discrepancy between the number of pages recorded by our application and the page count reported in the Azure Portal for Azure AI Document Intelligence during September 2026.

Our application-side statistics show 63,107 pages, while the Azure Portal reports 73,748 pages, resulting in a difference of 10,641 pages (approximately 16.86% higher than our application-side count).

We would like Microsoft Support to investigate this discrepancy and clarify how the service calculates and reports processed pages.

2. Environment and Usage Details

Service: Azure AI Document Intelligence

Model: prebuilt-invoice

API usage period: September 1–30, 2026

Input file formats: PDF, JPG, PNG only

Analysis feature: ocrHighResolution enabled

Application: Java application using the Azure Document Intelligence SDK

Resource usage: We have confirmed that only this application uses the Azure Document Intelligence resource.

• Request pattern: One prebuilt-invoice analysis call per submission.

For page counting, our application counts each PDF page as one page and each JPG/PNG image as one page. We understand that this is consistent with the documented page-counting rules for these file formats.

3. Statistics Comparison

ItemPage CountApplication-side statistics63,107Azure Portal statistics73,748Difference10,641Difference as a percentage of application-side statisticsApproximately 16.86%Our application logs the file name and page count immediately before calling beginAnalyzeDocument(...). The application-side total is based on the pages associated with successful OCR processing.

We reviewed the September API access records and identified only 10 failed requests. All 10 involved single-page PDF files, and the returned error message was:

Shutdown in progress

Even if all 10 failed requests were counted by Azure, they would account for only 10 pages and therefore cannot explain the discrepancy of 10,641 pages.

4. Questions for Microsoft Support

We would appreciate your assistance with the following questions:

1. Processed Pages calculation: What exactly is included in the Azure Portal's Processed Pages metric? Are pages from requests that fail, time out, or return an error included if the service has already started processing them?

ocrHighResolution usage: Does enabling ocrHighResolution affect the Processed Pages metric or only the applicable billing charges? Could it cause any additional page usage to be recorded for a single analysis request?

Usage reconciliation: Could you help us reconcile the 63,107 pages recorded by our application with the 73,748 pages reported by Azure for September 2026? If possible, please investigate the service-side request and page-processing records for our resource during this period.

Error handling: For the 10 requests that returned Shutdown in progress, could you clarify whether the service had processed any pages before returning the error, and whether those pages were included in the reported usage?

5. Expected Outcome

We would like to understand the exact reason for the 10,641-page discrepancy and confirm whether the Azure Portal metric accurately reflects the pages processed by our application.

If the discrepancy is caused by additional requests, service-side processing behavior, or a metric calculation issue, please provide the relevant details and recommendations for verifying future usage.

We can provide the resource name, region, request timestamps, application logs, and other relevant diagnostic information as needed.

6. Billing Calculation

The Azure Portal reports 73,748 processed pages for September 2026, but the corresponding charge is approximately JPY 109,100. Could you please explain how this amount was calculated? Please provide a breakdown of the applicable unit prices, the number of billable pages, any additional charges associated with ocrHighResolution, and any other billing adjustments or charges included in this amount. We would also like to understand whether the billed page count is expected to match the Processed Pages metric.

Answer 1

Recalculate the September total using Processed Pages → Total (Sum) rather than Count, because ProcessedDocumentPages is defined as a page-count metric whose supported/default aggregation is Total (Sum). ^1^

Correct the metric query

Your screenshot shows Processed Pages, Count. In Azure Monitor:

1. Open the Document Intelligence resource.
2. Go to Monitoring → Metrics.
3. Select Processed Pages.
4. Change Aggregation from Count to Total (Sum).
   • Count counts metric measurements.
   • Sum adds the values contained in those measurements. ^2^
5. Set a custom range covering the complete month using the same timezone as the application:
   • Start: 2026-09-01 00:00:00
   • End: 2026-10-01 00:00:00
6. Record the new total.
7. Select Apply splitting → FeatureName to identify whether the additional usage is attributed to prebuilt-invoice, high-resolution extraction, or another feature. Microsoft’s Document Intelligence usage procedure specifically documents splitting Processed Pages by FeatureName. ^3^

The daily comparison also appears to use different time boundaries: the metric screenshot is in UTC+08:00, while the application’s logging timezone is not stated. This can explain pages moving between adjacent days—such as September 8–10—but not necessarily the full monthly difference. Recalculate both systems against identical UTC boundaries before comparing daily totals.

What the available documentation establishes

• Processed Pages is described as the number of document pages processed. Its REST metric name is ProcessedDocumentPages, unit is Count, aggregation is Total (Sum), and its dimensions are ApiName, FeatureName, UsageChannel, and Region. ^1^
• ocrHighResolution is an optional add-on capability that performs enhanced extraction and can incur an additional charge. The documentation does not state that enabling it creates extra logical document pages in Processed Pages. Therefore, it should not be assumed to explain 10,641 additional pages without confirming the FeatureName split and billing meters. ^4^
• If no pages range is supplied, the service processes the entire document. If one is supplied, only the specified pages are processed. ^5^

The public documentation does not define whether partially processed pages from a request ending in Shutdown in progress are emitted in Processed Pages. It also does not document that specific error’s metering behavior. The ten one-page failures therefore cannot be used to explain—or definitively exclude—service-side partial processing, but they are far too few to account directly for a 10,641-page difference.

If the Total (Sum) result still differs

A backend reconciliation requires an Azure support case; Q&A participants cannot inspect resource-level service or metering records. Include:

• Subscription and resource IDs, resource region, pricing tier.
• API version and Java SDK package/version.
• Exact UTC interval: September 1 through October 1.
• Metric export using Total (Sum), split separately by:
  • FeatureName
  • ApiName
  • UsageChannel
  • Region
• Cost Management export grouped by Resource and Meter.
• Request/operation IDs and UTC timestamps for the ten Shutdown in progress responses.
• Application totals including all submissions, not only successful OCR results.
• Evidence that automatic retries are disabled or logged separately.
• A sample of file hash, page count, submission timestamp, operation ID, and final status.

Request these specific findings:

1. Service-side submitted and processed page totals.
2. Whether retry attempts or polling/recovery behavior created additional analysis operations.
3. Attribution of all 73,748 pages by API and feature.
4. Whether pages processed before failed terminal states were metered.
5. Billing-meter totals for base invoice analysis versus ocrHighResolution.
6. Whether the resource was affected by a September 2026 telemetry or aggregation incident.

For future investigations, retain the POST request/operation ID. Document Intelligence is asynchronous, and Microsoft recommends saving that ID before retrying; results can be retrieved for up to 24 hours. ^6^

For Java, temporarily enable sanitized HTTP-level logging with AZURE_HTTP_LOG_DETAIL_LEVEL=BASIC or HEADERS; avoid body logging in production because documents can contain sensitive data. ^7^

---

References

1. Supported metrics for Microsoft.CognitiveServices/accounts
2. Azure Monitor Metrics aggregation and display explained
3. Check my usage and estimate the cost - Document Intelligence - Foundry ...
4. Document Intelligence add-on capabilities
5. Frequently asked questions
6. Troubleshooting latency issues in Azure Document Intelligence in Foundry Tools
7. Configure logging in the Azure SDK for Java