Claude AI Delivers 5–10× Faster CMR Processing: What Changed and Why It Matters
The short answer: by replacing asynchronous polling with a synchronous AI call, Claude API eliminates the biggest source of latency in CMR document extraction — the wait. Here is the technical breakdown and what it means for operators.
The bottleneck: asynchronous document processing
Before the Claude integration, all CMR document extraction ran through Microsoft Azure Content Understanding (CUS). Azure CUS is a powerful service — it handles complex multi-page logistics bundles well, segments documents into logical sections, and returns structured field data. But its API follows an asynchronous pattern that introduces a structural performance ceiling.
When you submit a document to Azure CUS, the service returns HTTP 202 with an Operation-Location header. You then poll that URL — typically every 2–3 seconds — until the status field changes from running to succeeded. For a straightforward 2-page invoice + CMR bundle, this process typically takes 20–35 seconds. For larger bundles, it can exceed 45 seconds.
The async pattern is not a flaw — it is designed for very large documents and high-concurrency workloads where results genuinely cannot be returned inline. But for the typical CMR + invoice bundle (1–5 pages, 0.5–3 MB), the overhead of queue placement, polling round-trips, and result retrieval adds far more latency than the actual AI inference time.
How Claude API changes the architecture
Claude API — specifically the Messages API — accepts a PDF document as a base64-encoded content block and returns extracted data inline in the same HTTP response. There is no polling, no operation ID, no status check. One POST request, one response, done.
This synchronous model means end-to-end extraction latency equals AI inference time plus one round-trip network cost. For claude-sonnet-4-5 processing a 1–3 page bundle, that lands at 3–8 seconds. Larger bundles (4–10 pages) typically complete in 6–15 seconds. The variance is low because there is no queue position uncertainty — only inference load on Anthropic's infrastructure.
The practical effect for CMR operators: the extraction result is available before the user has finished reviewing the upload confirmation screen. The perception of waiting disappears.
Head-to-head: Claude vs Azure Content Understanding
| Dimension | Claude API | Azure CUS |
|---|---|---|
| Document submission | POST → 200 + JSON | POST → 202 + OperationLocation URL |
| Result delivery | Inline in same response | Requires polling until status = Succeeded |
| Average latency (1–3 pages) | 3–8 seconds | 20–35 seconds |
| Average latency (4–10 pages) | 6–15 seconds | 30–50 seconds |
| Latency variability | Low — direct inference | High — queue position + poll interval |
| Network round-trips | 1 | 2 + N polls (typically 4–12) |
| Async job queue required | No | Yes |
| Concurrent request scaling | Horizontal — stateless | Stateful — tied to operation IDs |
Benchmark conditions: production workloads, Western Europe endpoints, PDF bundles 0.5–4 MB, January–August 2026. Latency measured from document upload to extracted data available in UI.
Extraction capability comparison
Speed matters only if the extraction quality is at least comparable. The Claude integration was designed to match the output schema of Azure CUS precisely — the same domain models, the same field names, the same candidate arrays — so there is no downstream data model change.
| Field | Claude approach | Azure CUS approach |
|---|---|---|
| Invoice number | From invoice pages only — never from CMR waybill | From combined document analysis |
| Multi-invoice bundles | All invoices found per document scan | Per-document, multi-segment |
| Sender / consignee data | Full address extraction with ISO country codes | Full address extraction |
| Gross weight | Primary value + alternative candidates array | Primary value + segment candidates |
| Pallet / package count | Primary value + alternative candidates array | Primary value + segment candidates |
| Goods description | 1–3 word summary in document's own language | Structured label extraction |
| Date format | Normalised to DD.MM.YYYY | Varies by document |
One notable difference: Claude returns goods descriptions as a concise 1–3 word summary in the document's own language (e.g. “Kaffee”, “Elektronika”, “Meble”, “Продукты питания”). Azure CUS returns a longer structured label derived from document content. For the CMR form, the brief summary is more appropriate for Box 6 (nature of the goods), which has limited space.
Data privacy with Claude API
Before enabling Claude mode in production, you need to understand how Anthropic handles the document content your backend submits. The short answer is favourable: Anthropic does not use API inputs to train models, and enterprise DPAs are available.
Anthropic's API usage policy explicitly states that content submitted via the API is not used to train or improve Claude models. Your CMR bundles and invoices are processed transiently — not stored for model improvement, not indexed for analytics, not retained beyond the API response lifecycle.
Anthropic provides a GDPR-compliant Data Processing Agreement (DPA) for enterprise API customers. The DPA covers the requirements of GDPR Article 28, defines Anthropic's role as a data processor acting on your instructions, and lists applicable sub-processors. Sign the DPA before sending documents containing personal data (sender/consignee names and addresses).
Anthropic holds SOC 2 Type II certification, independently auditing the security, availability, and confidentiality controls applied to API infrastructure. This satisfies a core requirement of most enterprise security questionnaires and aligns with NIS2 obligations for logistics operators using AI sub-processors.
Anthropic API traffic is processed under standard contractual clauses (SCCs) for GDPR-adequate data transfer. If your organisation requires EU data residency for document processing, verify current region availability with Anthropic's enterprise team before production deployment.
Both Microsoft Azure Content Understanding and Anthropic Claude API are now listed as sub-processors in Logi Link Up's privacy policy, with signed DPAs in place. The active processing engine is controlled by the deployment configuration and is transparent to end users.
Which mode should you use?
For most operators, Claude mode will be the better choice once you have signed Anthropic's DPA. The speed improvement is significant enough to meaningfully affect operator workflow — extracting data for a 3-invoice bundle in under 8 seconds versus waiting 35+ seconds changes how staff interact with the tool.
There are scenarios where Azure CUS may remain preferable: very large document bundles (15+ pages), complex mixed document types where CUS's segment-aware extraction provides higher accuracy, or environments with strict EU data residency requirements that cannot yet be satisfied by Claude API's infrastructure footprint.
The feature flag architecture means you can run both in parallel across deployments — Azure CUS on one environment, Claude on another — and compare results before committing production traffic to either.
Frequently asked questions
How much faster is Claude AI for CMR document processing?
In our production benchmarks, Claude API returns extracted invoice and CMR data in 3–8 seconds on average, compared to 20–45 seconds for Azure Content Understanding in asynchronous mode. This represents a 5–10× improvement in end-to-end processing time. The main reason is architectural: Claude returns results synchronously (inline), while Azure CUS uses an asynchronous polling pattern that introduces queuing and network overhead on top of the actual AI processing time.
Why is Claude API faster than Azure Content Understanding for logistics documents?
The speed difference comes from the processing model, not just raw inference speed. Azure Content Understanding uses an asynchronous 202/OperationLocation pattern: you submit a document, receive a polling URL, and repeatedly check for results until they are ready. Each poll is an additional HTTP round-trip, and queue position adds variable latency. Claude API processes the document in a single synchronous HTTP request and returns extracted data inline in the same response — eliminating polling entirely. For CMR and invoice documents (typically 1–5 pages), this synchronous path is almost always faster in wall-clock time.
Is it safe to send CMR documents and invoices to Claude API?
Yes, with the right contractual and technical controls in place. Anthropic offers a Data Processing Agreement (DPA) for enterprise API customers that covers GDPR requirements under Article 28. Critically, Anthropic does not use API request content to train or improve Claude models by default — your documents are processed and discarded, not retained for training purposes. Anthropic holds SOC 2 Type II certification and processes data in enterprise-grade infrastructure. You should sign Anthropic's DPA before sending personal data (sender/consignee names and addresses) through the API.
Does switching to Claude AI break existing CMR integrations?
No. The Claude extraction mode was implemented behind a feature flag (DocumentProcessing:Mode = 'Claude') with a shared IContentUnderstandingService interface. Domain models — CmrFormData, CusFormDataExtractionResult, and all downstream data structures — are identical regardless of which extraction engine is active. The API contract, response format, and UI behavior are unchanged. Switching modes requires only a configuration change; no code modifications or database migrations are needed.
Which Claude model is used for CMR document processing?
The default model is claude-sonnet-4-5, which offers the best balance of extraction accuracy and processing speed for logistics documents. The model is configurable via the Claude:Model setting in appsettings.json, so operators can switch to newer or more capable Anthropic models as they become available without code changes. For very complex multi-page bundles (10+ pages with mixed document types), claude-opus-5 may provide better extraction accuracy at somewhat higher latency.
Can Claude extract data from multi-invoice PDF bundles?
Yes. The Claude extraction prompt is specifically designed to scan the entire document from first page to last and return one entry per invoice page found. Invoice numbers are taken only from pages clearly labeled as invoices — never from CMR waybill or transport order pages. Weight, package count, and pallet candidates from different document sections are also captured and returned as structured arrays, matching the multi-segment extraction behaviour of the Azure Content Understanding service.
See 5–10× faster CMR extraction in action
Upload a PDF bundle and watch Claude extract invoice data, sender and consignee details, weights, and pallet counts — in seconds.
Try CMR Generator free →