Recommended Azure Setup and Monthly Cost for Document Processing Pilot (500–2,000 Emails/Month)

For a low-volume pilot (500–2,000 emails/PDFs per month), a minimal, pay‑as‑you‑go, serverless setup is recommended so that costs scale with usage and there’s no upfront overprovisioning.

Recommended minimum Azure setup

1. Azure Functions

• Use a serverless hosting plan (Consumption or equivalent) so that compute scales automatically and you only pay for executions and execution time.
• Functions act as the backend to:
  • Receive triggers from email ingestion or workflow (for example, via Logic Apps or Power Automate).
  • Call Azure AI Document Intelligence for analysis.
  • Store extracted results in storage or a database.
• This pattern is explicitly recommended for document processing workloads, where Functions “enables workloads to process incoming documents and trigger model processing pipelines.”

2. Azure AI Document Intelligence

• Use Document Intelligence as the core document processing service to extract text, key-value pairs, and tables from PDFs.
• For a pilot with uncertain traffic patterns and relatively low volume, use Standard (pay‑as‑you‑go) deployment types first, such as Global Standard or Data Zone Standard. These are recommended for “low-to-medium, bursty, or exploratory workloads” and avoid reserved capacity.
• As volume and patterns stabilize, consider moving critical paths to Provisioned deployment types (for example, Global Provisioned or Data Zone Provisioned) to get predictable throughput and cost benefits.

3. Azure Storage

• Use Blob Storage or Data Lake Storage to store:
  • Raw PDFs (hot tier for active processing).
  • Processed outputs (JSON, CSV, etc.).
• For a pilot, a single storage account with a hot tier for raw files is sufficient. Data Lake Storage can be added if more advanced analytics or ML workflows are needed later.

Cost planning and estimation

• The main cost drivers for this architecture are:
  1. Model inference usage via Foundry (Document Intelligence).
  2. Document ingestion and processing via Document Intelligence.
  3. Storage and any indexing/search if added later.
• For pilots and exploratory workloads, guidance is to:
  • Use pay‑as‑you‑go and “scale out as needed rather than investing in large-scale resources at the start.”
  • Use preconfigured estimates in the Azure pricing calculator for document processing architectures and adjust for the expected document volume.
• For more predictable workloads, cost can be optimized by:
  • Using provisioned throughput units (PTUs) or reservations for Foundry deployments instead of pure pay‑per‑token.
  • Using commitment tier pricing for Document Intelligence.
  • Using reserved capacity and lifecycle policies to rightsize storage accounts.
• For a pilot at 500–2,000 documents/month, the overall architecture described is explicitly characterized as “a starting solution that’s suitable for proof of concept” with minimal resource requirements (for example, smallest serverless host for the function app). Detailed dollar amounts are not provided in the context, so the Azure pricing calculator must be used to derive monthly cost.

Where to implement order-number extraction logic

• For a pilot, the architecture guidance emphasizes using serverless components (Logic Apps and Functions) and starting with a minimal, pay‑as‑you‑go setup.
• Logic Apps (and by extension Power Automate, which shares similar workflow concepts) are recommended as orchestrators to coordinate:
  • User input.
  • Document storage.
  • Document processing.
  • Storage of results.
• Azure Functions are recommended as the backend for data processing, including configuring input to Document Intelligence and storing output.
• A pragmatic pattern for a pilot is:
  • Use a workflow tool (Logic Apps/Power Automate) for orchestration and simple routing.
  • Implement more complex parsing and business logic (such as robust order-number extraction across multiple document types) in Azure Functions, where code can be versioned and tested more easily.

Suitability of Azure AI Document Intelligence vs. Azure Content Understanding

• Document Intelligence is designed specifically for intelligent document processing and is used in reference architectures to process PDF forms and other documents, including:
  • Invoices and payment records.
  • Purchase orders.
  • Safety, incident, and compliance records.
  • Customer feedback forms.
  • Employee records.
  • Documents with handwritten notes.
  • Custom documents from a specific domain.
• It provides:
  • Prebuilt models for invoices, receipts, ID cards, business cards, and other document types.
  • Custom template and custom neural models that can be trained for domain-specific documents.
• The context does not describe Azure Content Understanding, nor does it compare it directly to Document Intelligence. Within the provided information, Document Intelligence alone is presented as sufficient and recommended for processing purchase-order-like forms, invoices, and similar documents in automated PDF forms processing and custom document processing solutions.

Summary

• Use a minimal, serverless architecture:
  • Azure Functions (serverless) for backend processing and integration with Document Intelligence.
  • Azure AI Document Intelligence (Standard/pay‑as‑you‑go) for the pilot, with an option to move to Provisioned/commitment tiers later.
  • Azure Blob Storage or Data Lake Storage for raw and processed documents.
• Start with pay‑as‑you‑go and use the Azure pricing calculator and preconfigured estimates to approximate monthly costs for 500–2,000 documents.
• Use workflow tools (Logic Apps/Power Automate) for orchestration and Azure Functions for core extraction logic.
• For the described use case (purchase orders, order confirmations, delivery notices, invoices), Document Intelligence is explicitly recommended and sufficient based on the reference architectures.

References:

• Automate document classification in Azure
• Automate PDF forms processing
• Build and deploy custom document processing models on Azure