AWS Textract Alternative - What a Production Textract Pipeline Takes vs Parseur

Amazon Textract is an AWS API that analyzes documents and returns text, forms, tables and Query results. To run it in production, your team builds the pipeline around it: ingestion, job orchestration, schema mapping, validation, retries, monitoring and delivery. Parseur is a managed document processing platform that already includes that pipeline, from email or API intake to validated JSON delivered by webhook.

Choose Textract if you want an AWS-native pipeline your engineers own and control. Choose Parseur if you want recurring documents turned into structured data in your business systems without building and running that layer.

Key Takeaways

• Textract is a document analysis API. It returns text, forms, tables and Query results as Block objects. Your team builds ingestion, orchestration, schema mapping, validation, retries, monitoring and delivery around it.
• Parseur is the managed pipeline. It covers email, upload and API intake, extraction into your own fields, AI document splitting, validation, failure alerts and webhook delivery with retries, and operations teams can change extraction without a developer.
• Cost depends on the Textract API you call. At 100,000 pages a month, Textract's Forms plus Tables analysis costs about $6,500 at AWS's published rates, before other AWS services or engineering. Parseur's 100,000-page plan is $3,699 a month for the whole pipeline. AnalyzeExpense is cheaper at $1,000, but only covers invoices and receipts.
• New Textract builds need their own human review. AWS closed Amazon A2I to new customers on July 30, 2026.
• Pick by ownership, not by OCR. The real question is how much of the document processing application your team wants to build and operate.

Amazon Textract vs Parseur at a Glance

What Is the Best Alternative to Building a Pipeline Around Amazon Textract?

The main alternative to building a production pipeline around Amazon Textract is a managed document processing platform such as Parseur, which handles intake, extraction into your own schema, validation, failure alerts and webhook delivery as one service. Other cloud APIs, such as Google Document AI and Azure AI Document Intelligence, are not really alternatives to the build. They replace the extraction call and leave the same pipeline to you.

The question usually lands on a backend or platform lead at a company that already runs on AWS. Someone asked them to automate supplier invoices or order forms, and Textract was the obvious first stop: the account exists, the credits exist, procurement is already done. The boto3 prototype worked in a sprint. Then operations asked for email intake, finance wanted line items in NetSuite with ISO dates, a supplier sent a 90-page bundle, and the "quick Textract script" picked up an on-call rotation.

Textract and Parseur sit at different layers of that architecture. For asynchronous processing, AWS documents a flow where a document is stored in Amazon S3, a Textract Start operation begins analysis, Amazon SNS publishes the completion status, Amazon SQS or AWS Lambda receives it, and the application calls a Get operation to retrieve the results. The application then still maps, validates, retries, monitors, stores and delivers.

The shorter Parseur path does not make every production requirement disappear. Parseur documents schema mapping, normalization, required-field and choice validation, failure notifications, webhooks and custom Python post-processing. Requirements outside those still need downstream logic.

Parseur in Production

Parseur has run in production since 2016 and has processed more than 100 million documents. It handles volumes from 1,000 to 1 million pages a month through the web app and the API, with 99.9% uptime or better. Customer data is processed and stored in the European Union, Parseur is SOC 2 Type II compliant and GDPR compliant, and each mailbox has its own retention period. See Parseur security for details.

Parseur's extraction accuracy is documented in three public benchmarks run in October 2026. Amazon Textract was not part of them, so they show how Parseur handles difficult documents, not a head-to-head result:

• Handwriting OCR Benchmark 2026: 209 of 209 fields correct on seven scanned, partly handwritten Texas Railroad Commission oil and gas forms, the only perfect score among six tools.
• Multilingual Invoice Extraction Benchmark 2026: 200 of 200 fields correct on German, French, Japanese and Korean invoices, including a two-page invoice and a phone photo, the only zero-error result among six IDP tools.
• LLM Document Extraction Benchmark 2026: ranked first of four tools across seven bills of lading, and one of two tools that returned all 47 container numbers from a 20-page bill of lading, where ChatGPT and Gemini returned null with no warning.

The other difference is who can change the workflow. In a Textract build, a new field, supplier format or document type usually means a code change and a redeployment. In Parseur, an operations or finance lead edits fields and instructions in the app, and a developer connects the output once.

What Amazon Textract Actually Does

Amazon Textract is an AWS service that detects and analyzes information in documents. Its APIs extract lines and words, form fields as key-value pairs, tables, selection elements such as checkboxes, signatures and answers to Queries. AWS also offers custom Query adapters and specialized APIs for expenses and lending.

The AnalyzeDocument API lets developers request features such as TABLES, FORMS, QUERIES, SIGNATURES and LAYOUT. Textract returns interconnected Block objects: a table has TABLE and CELL blocks, a form uses KEY_VALUE_SET blocks, and a query links QUERY and QUERY_RESULT blocks, each with relationships, geometry and confidence.

That structure is detailed, but it is not the schema your application needs. An accounts payable system wants a JSON object with invoice_number, supplier_name, invoice_date, currency and an array of normalized line items. Getting from Blocks to that object is your code.

Current Amazon Textract Document Limits

These limits do not rule Textract out. They decide the design. Multi-page PDFs need the asynchronous StartDocumentAnalysis and GetDocumentAnalysis operations, which bring their own job lifecycle, quotas and failure modes.

What Does a Production Amazon Textract Pipeline Require?

A production Amazon Textract pipeline needs document ingestion, asynchronous job orchestration, schema mapping, normalization, validation, retries and failure handling, document splitting, monitoring, a path for uncertain results, and persistence and delivery. Textract does the document analysis. The surrounding application does everything else. Here is each piece, and how Parseur handles it.

1. Document Ingestion

Before Textract can analyze a document asynchronously, the document must be in Amazon S3. AWS passes the S3 object through the DocumentLocation parameter of StartDocumentAnalysis.

Uploads follow a path such as application, then S3, then an event or queue, then processing. Email needs one more layer. An invoice attached to an incoming email does not travel from the inbox to Textract by itself. Something has to receive the email, find the right attachment, and place it in S3 before the job starts.

How Parseur handles it: each Parseur mailbox has its own email address, so suppliers and colleagues can forward, CC or BCC documents to it, and Parseur splits the email body and attachments into separate records. Files can also be uploaded, or sent through the Parseur API as binary documents or as email-like payloads with sender, subject, body, headers and attachments.

2. Job Orchestration

For multi-page production processing, Textract uses asynchronous jobs: StartDocumentAnalysis returns a JobId, Textract processes the S3 document, SNS publishes the completion status, SQS or Lambda receives it, and GetDocumentAnalysis retrieves the results.

A minimum architecture looks like S3, then Lambda or Step Functions, then StartDocumentAnalysis, SNS, SQS, Lambda and GetDocumentAnalysis. AWS advises against polling Get operations, which can be throttled, and describes a single SQS queue as the simpler pattern for many concurrent jobs.

The lifecycle adds more to track. A JobId is valid for seven days, and asynchronous results are kept for seven days unless you set your own S3 destination through OutputConfig. A ClientRequestToken provides idempotency. Starting too many jobs at once can raise a LimitExceededException, so high volumes need a queue to absorb bursts.

How Parseur handles it: Parseur processing is asynchronous too, but Parseur runs the queue. You do not assemble a start, notify and retrieve lifecycle around the extraction engine.

3. Turn Textract's Output Into Your Business Schema

Textract returns document analysis, not your data contract, so a production application maps Blocks to the stable schema its ERP, database or API expects.

Textract might find "Invoice No.: INV-8493", a date elsewhere on the page and a table of line-item cells. Your application wants:

{
  "invoice_number": "INV-8493",
  "supplier": "Acme Ltd",
  "invoice_date": "2026-09-01",
  "currency": "USD",
  "total": 9420.5,
  "line_items": [{ "sku": "A-100", "quantity": 4, "unit_price": 120.0 }]
}

The transformation layer handles field mapping (Invoice Number, Invoice # and Invoice No. all become invoice_number), normalization (09/01/2026 and 1 Sep 2026 both become 2026-09-01), tables (Blocks and relationships become arrays of line items) and maintenance as suppliers change their layouts. Textract confidence runs from 0 to 100, and AWS notes that financial workflows may need thresholds of 90 or higher, so the mapping layer also decides what to do with low scores.

That maintenance is where homegrown pipelines tend to break. Every new supplier brings a new label, table shape or date format. Queries help, since "What is the invoice number?" works across layouts, but they are capped at 15 per page synchronously or 30 asynchronously, are priced on top of other features, and still return results your code must map.

How Parseur handles it: Parseur starts at the business schema. You create a Simple Field for each single value and a Table Field with columns for repeating data such as line items, add output formats for dates and numbers, and write plain-language instructions per field or for the whole document, such as "normalize dates to YYYY-MM-DD". The AI engines extract from those definitions rather than per-layout templates, so one mailbox covers many senders. A new supplier quirk is an edited instruction, not a deployment.

4. Validate the Extracted Data

A pipeline is not finished because it produced JSON. Before data reaches an ERP, CRM or database, something has to check that it is complete, correctly formatted and acceptable for the business.

For an invoice that means questions such as: is invoice_number present, is the total a number, is the currency supported, does subtotal plus tax equal the total, does the supplier exist in the ERP, does the purchase order exist, and is any key value below the confidence threshold. Extraction confidence and business validity are different things. A value can be read with 99% confidence and still break a rule.

In a Textract build, this is a Lambda function or service running JSON Schema or Pydantic checks, lookups against the ERP or database, and a queue for failed records.

How Parseur handles it: fields take output formats for dates and numbers, and a field can be set to "Fail processing if field not found". Parseur runs three built-in checks, schema, required-field and choice-field validation, described on its normalization and validation page. A failing document is marked Process Failed, shows in the app, triggers an email notification and, when configured, fires a process-failed webhook. Python post-processing rules, available on plans from 10,000 pages a month, can reshape data, run lookups or apply custom business rules.

Parseur does not return per-field confidence scores. A Parseur workflow defines what must be true for a document to pass and fails it when that is not the case. Teams that specifically need confidence-based routing should plan for that difference.

5. Build Retries, Idempotency and Failure Handling

Production reliability means predictable behavior when an API throttles, a job fails, a document is invalid, or the destination system is down.

AWS documents Textract errors including throttling, provisioned throughput exceeded, service unavailability, invalid S3 objects, unsupported documents and job limits. They need different responses:

• Transient failure: retry with exponential backoff and jitter. AWS's SDK example allows up to five retries.
• Capacity limit: queue and retry later, using SQS to smooth bursts.
• Invalid or unsupported input: stop and route to exception handling.
• Repeated failure: alert or send to an error queue.
• Success: continue to validation.

Retries also need idempotency. StartDocumentAnalysis accepts a ClientRequestToken, valid for seven days, so a repeated request returns the same JobId instead of starting a duplicate job.

Then there is the far end. The ERP, CRM, database or internal API that receives the data can be down too, and the pipeline needs a delivery policy for that.

How Parseur handles it: if an eligible webhook delivery fails, Parseur retries it up to five times after the original attempt, six attempts in total, with exponential backoff, for HTTP 408, 429 and 5xx responses, network errors and timeouts, as documented in the Parseur webhook docs. Webhook logs keep the payload, every attempt, response codes, response bodies, errors and timings.

6. Handle Compound Documents and Document Splitting

A multi-page file is not always one business document, so a pipeline handling bundles has to find where each document starts and ends before it extracts anything.

A 90-page PDF might hold an invoice, a delivery note, a purchase order, terms and conditions and a second invoice. Even if Textract reads every page, the application still has to work out that there are two invoices, separate the purchase order from the delivery note, and route each to the right schema.

AWS publishes an end-to-end architecture that splits and classifies with Amazon Comprehend, extracts with the right Textract API, and coordinates with Step Functions and Lambda. Textract's Analyze Lending API includes splitting and classification, but only for lending packages. Invoices, purchase orders and delivery notes need that layer built.

How Parseur handles it: document splitting is a mailbox setting. A bundle can be split every fixed number of pages, by page ranges, before or after a keyword, or with AI when boundaries are unpredictable. AI splitting classifies page types and groups related pages, each result is extracted as its own record, and a split can be reversed. Each split maps to that mailbox's schema, so document types with different fields need separate mailboxes, and unusual bundles should be tested on real samples.

7. Monitor the Pipeline in Production

Production monitoring has to answer more than "is the API up": are documents moving, is the extracted data valid, and did it reach its destination?

How Parseur handles it: Parseur monitors the document workflow end to end, not just the extraction call.

• Configurable alert emails tell your team when documents fail to process or fail to export.
• "Process failed" webhooks fire when a document fails validation, so your incident or ticketing tool can open a case automatically.
• "Export failed" webhooks fire when a delivery to your endpoint fails after retries, so a broken ERP endpoint never fails silently.
• Processing and webhook logs record every document status, payload, delivery attempt and response code.

Your own monitoring still covers the systems that receive the data, but Parseur tells those systems, and your team, when something on its side needs attention.

How it works around Textract: Amazon Textract publishes service metrics to Amazon CloudWatch, including SuccessfulRequestCount, ThrottledCount, ResponseTime, ServerErrorCount and UserErrorCount, and you can set CloudWatch alarms on them. Those metrics stop at the Textract boundary. The rest of the pipeline needs its own observability:

A Textract job can succeed while the workflow fails: a required field below threshold, a schema rejection, an SQS backlog, an ERP outage. API success is not workflow success.

8. Decide What Happens When Extraction Is Uncertain

A production pipeline needs an explicit path for results that should not continue automatically.

• Validation passes: accept and continue.
• Validation fails: reprocess, correct or route to an exception workflow.
• Ambiguous or low-confidence extraction: route to human review when the workflow needs it.
• Broken or unsupported document: stop and send to an exception queue.
• Delivery fails: retry according to the delivery policy.

Human review with Textract has changed in 2026. Textract's HumanLoopConfig parameter connects analysis to Amazon Augmented AI (A2I) for human review. AWS moved A2I to maintenance in its June 2026 service availability update, and it closed to new customers on July 30, 2026. Existing A2I customers keep it, but new Textract builds that need human review must design their own review application.

How Parseur handles it: documents that fail validation are marked Process Failed, flagged in the app, reported by email and optionally sent to a process-failed webhook. A team member adjusts field instructions and reprocesses, or the webhook pushes the failure into an existing review or ticketing tool. Teams that need reviewer assignment, approvals or an audit trail per correction should plan that downstream.

9. Persist and Deliver the Result

Once data is extracted and validated, the pipeline must store the right artifacts and deliver business records to their destination. Textract does not decide where your normalized invoice should live or how NetSuite, Salesforce or Postgres should receive it.

A Textract architecture decides where to store original documents, Textract output (kept seven days by default unless written to your S3 bucket through OutputConfig), normalized records and failed records, then builds the delivery path, for example S3, Textract, a validated record in a database, then Lambda, an API call or an event into the ERP.

How Parseur handles it: when processing completes, Parseur posts the parsed result as JSON to your webhook endpoint, which Parseur recommends over polling its API. For teams where operations owns the routing, the same data goes natively to Zapier, Make, Power Automate or n8n, and from there to NetSuite, Salesforce, a database or a spreadsheet. Your receiving system still owns its own retention and system of record.

AWS Textract vs Parseur - Who Owns Each Production Component?

The practical comparison is not which product extracts data. It is which parts of the production pipeline your team wants to design, operate and maintain.

Not every Textract build needs every row. It depends on document types, volume, existing AWS setup and downstream systems.

How Much Does Amazon Textract Cost at 100,000 Pages a Month?

At AWS's published US West (Oregon) rates for the first million pages a month, Amazon Textract's API fees for 100,000 one-page documents range from $1,000 with AnalyzeExpense to about $7,000 with Forms, Tables and Queries. Those figures cover the API only, before S3, Lambda, Step Functions, SQS, SNS, CloudWatch and the engineering to build and run the pipeline. Source: Amazon Textract pricing.

Parseur's 100,000-page plan is $3,699 per month, or $33,588 a year billed annually, and includes intake, extraction into your fields, validation, failure alerts and webhook delivery. One credit is one PDF or image page. Emails and spreadsheets count as one credit whatever their length.

Detect Document Text is the cheapest line, but it returns raw text, so every field still has to be found by your code. AnalyzeExpense is cheap too, but it only covers invoices and receipts, so purchase orders and delivery notes need AnalyzeDocument. For a general Forms plus Tables pipeline, the Textract API bill alone is higher than the Parseur subscription. For an invoice-only workload on AnalyzeExpense, Textract's API is cheaper, and the decision rests on what the surrounding pipeline costs to build and run. If documents average two pages, both lines double.

Compare Total Cost of Ownership, Not Just Prices

Textract TCO = API usage + supporting AWS services + engineering build + ongoing operations. Depending on the architecture, that includes S3, Lambda, Step Functions, SQS, SNS, a database, logging and monitoring, initial integration work, normalization and validation code, retry and exception handling, on-call support and a human review tool where required.

Parseur TCO = subscription + configuration and integration + remaining organization-specific logic, such as external lookups, monitoring of your receiving systems and human review where your process needs it.

A deeply AWS-native team may already have much of that infrastructure and tooling, which changes the math in Textract's favor. A team without it gets more value from moving those responsibilities to a managed platform. For a wider look at that trade-off, see build vs buy a document parser.

When Amazon Textract Fits

Amazon Textract is the right choice when document analysis should be a building block inside an AWS architecture your engineering team controls. For some organizations, it is clearly the right call:

• You are deeply AWS-native. Storage, queues, databases, monitoring, security controls and integrations already run on AWS.
• Engineering wants infrastructure-level control over intake, orchestration, transformation, validation, storage and exceptions.
• You are building a document processing product or platform, where owning the architecture is the point.
• Textract's capabilities match your documents: text, forms, tables, selection elements, signatures, Queries, adapters, and expense and lending analysis.
• You already run event-driven AWS infrastructure with S3, SNS, SQS, Lambda, Step Functions and CloudWatch, and the patterns are in place.
• You are comfortable owning the application layer, from mapping and validation to retries, monitoring and delivery.

For teams with AWS expertise that deliberately want to own the document processing architecture, that control is an advantage, not a cost.

When Parseur Fits

Parseur fits teams that need structured data from recurring documents without building and operating the document processing application themselves.

• Documents are necessary but not your product. The goal is invoice, order, shipping, lead or application data inside business systems, not extraction infrastructure to maintain.
• Operations should own the workflow. An operations or finance lead defines fields and instructions in the app. A new field or supplier format needs no code change.
• You need a proven platform: in production since 2016, more than 100 million documents, 1,000 to 1 million pages a month, EU processing, SOC 2 Type II and GDPR.
• Documents arrive through several channels, email, upload and API, and you do not want to build intake for each.
• You want output organized around business fields, with dates, numbers, addresses, text and tables, defined in the app and exposed through the API.
• You need production delivery and monitoring: JSON webhooks with retries, alert emails, and process-failed and export-failed webhooks.
• Speed to production matters more than infrastructure-level customization. The trade-off is less low-level control than a bespoke AWS build.

The Build-vs-Buy Decision

Choosing between Amazon Textract and Parseur is a build-vs-buy decision about the document processing application layer.

Most teams reach this decision late. Engineering evaluates AWS first because the account and the contract already exist, the prototype looks finished after a sprint, and the bill for email intake, schema mapping, retries and on-call arrives over the following quarters. The cheaper moment to decide is before the prototype becomes production. Run a week of real documents through both options and count what your team would have to build around each.

A Practical Example - 100,000 Supplier Documents a Month

A company receives 100,000 one-page supplier documents a month, invoices, purchase orders and delivery notes from hundreds of suppliers, by email and API. It needs email and API intake, varied layouts, line items, structured JSON, required-field validation, retries, monitoring, ERP delivery by webhook or API, and EU data handling.

Built around Textract, the architecture has about thirteen parts: an email and API ingestion layer, S3, SQS or events, Lambda or Step Functions, Textract, result retrieval, mapping to three schemas, normalization, validation, persistence, retries and exceptions, monitoring and alerts, and the ERP integration. The team decides how attachments reach S3, how the three document types are classified, what counts as a failure and which failures retry. It also gets full control over every choice.

With Parseur, the architecture has about six: email or API intake, extraction into defined fields and line items, normalization and validation, structured JSON, webhook delivery and the ERP. The company still configures its fields, connects its ERP and keeps business rules that depend on external systems. Parseur processes and stores the data in the EU.

At 100,000 documents a month, ingestion failures, throttling, validation exceptions, schema changes and delivery failures are weekly events, not edge cases. The question is who operates the systems that handle them.

Build the Document Processing Layer You Actually Want to Own

Amazon Textract gives engineering teams document analysis APIs to build a custom AWS architecture around. That buys control over ingestion, orchestration, transformation, validation, monitoring, storage and delivery, and the responsibility for all of it.

Parseur takes the managed route for teams whose invoices, purchase orders, sales orders, delivery notes, bills of lading, leads and applications need to become structured data in business systems, without building the pipeline first.

Last updated on November 3rd, 2026