How We Built an AI Document Parser That Processes 100K+ Hotel Documents a Month
About the Client
Our client is a US-based hospitality startup that works with more than 20,000 hotels across the country. Their operations depend on a constant stream of documents from hotel partners—invoices, folios, receipts, and statements—and nearly every hotel submits them in its own format. Before this project, their pipeline relied on traditional OCR, which failed so frequently on that format variety that a large reconciliation team had to correct the output by hand, slowing operations and adding cost with every new hotel they onboarded.
Results
100K+
documents processed monthly
95%
extraction accuracy, up from 80% in the pilot month
20,000+
hotel document formats supported
How we approached challenges uniquely
One pipeline for 20,000+ document formats
Instead of maintaining a brittle OCR template for every hotel's layout, we built format-aware prompt templates for OpenAI's GPT models, so a single pipeline could read invoices, folios, receipts, and statements no matter who sent them.
Vision models where OCR kept failing
Traditional OCR extracts characters, not meaning. GPT-5.4 reads a document the way a person does—understanding tables, labels, and layout—and OpenAI function calling forces the output into schema-valid JSON that maps directly to DynamoDB.
A queue that absorbs 100K documents a month
Every upload lands in Amazon S3 and enters an SQS queue before an AWS Lambda worker processes it. The queue smooths traffic spikes against OpenAI rate limits, retries transient failures automatically, and sends anything unprocessable to a dead-letter queue instead of losing it.
Humans only see documents worth their time
Every extraction carries a confidence score derived from schema validation and cross-field checks—line items that must sum to totals, dates that must parse to valid periods. High-confidence results flow straight into DynamoDB, while low-confidence documents are routed to the reconciliation team—and their corrections feed back into the prompt templates as few-shot examples.
Our process that took accuracy from 80% to 95%
- Discovery - We audited the client's document landscape—invoices, folios, receipts, and statements across 20,000+ hotel partners—and defined the JSON schemas their database needed for every document type.
- Pilot - In the first month we ran 10,000 real documents through the pipeline, reaching 80% extraction accuracy and building the measurement harness that told us exactly which formats and fields were failing.
- Iteration - Each month we refined prompts, added per-format templates and few-shot examples mined from human-corrected documents, and tuned confidence thresholds—raising accuracy with every cycle.
- Scale - We gradually ramped volume to the client's full load of 100,000+ documents per month at 95% accuracy, with serverless costs that scale with usage rather than headcount.
Technology we chose for this project
AI & Data Extraction
- OpenAI GPT-5.4
- OpenAI Function Calling
- Node.js
AWS Infrastructure
- AWS Lambda
- Amazon SQS
- Amazon S3
- Amazon DynamoDB
What We Did
We designed and built an end-to-end AI document processing pipeline in four months with a team of four AI engineers. Documents uploaded by hotel partners land in Amazon S3, enter an Amazon SQS queue, and are picked up by AWS Lambda workers. Each worker renders every page to a high-resolution image, extracts its text layer, and splits pages into overlapping slices so nothing is lost at the cut lines. OpenAI GPT-5.4 reads the slices and text against a strict extraction schema, and function calling constrains the response to schema-valid JSON that is written directly to DynamoDB.
Around that core we built the systems that make AI reliable in production: per-format prompt templates, confidence scoring on every extraction, a human review queue for low-confidence results, and a feedback loop that turns reviewer corrections into few-shot examples—so the pipeline gets more accurate the longer it runs.
Result & Impact
The pilot month processed 10,000 documents at 80% extraction accuracy. By continuously refining prompts, templates, and confidence thresholds while scaling volume, the pipeline now handles the client's full load of more than 100,000 documents a month at 95% accuracy. The pipeline launched on GPT-4.1, and because extraction is schema-driven, upgrading to GPT-5.4 when it arrived was a configuration change—not a rebuild.
The impact on operations was immediate. Work that previously required a large reconciliation team correcting failed OCR output now runs largely untouched by human hands—the team reviews only the small share of documents the pipeline flags as uncertain. Documents that once sat in a backlog are in the database within minutes of upload, and the serverless architecture means costs grow with document volume, not headcount.
Frequently Asked Questions
Why did traditional OCR fail for this client?
OCR works best when documents follow predictable templates. With 20,000+ hotels each submitting invoices, folios, receipts, and statements in their own layouts, no template library could keep up. OCR also extracts characters without understanding meaning, so even successful scans produced data that needed human reconciliation before it could enter the database. This is why teams are replacing standalone OCR with intelligent document processing pipelines built on vision-capable language models.
How does the AI pipeline convert a scanned document into a database record?
Each document uploaded to Amazon S3 triggers a message on an Amazon SQS queue. An AWS Lambda worker picks it up, renders every page to a high-resolution image, extracts its text layer, and splits pages into overlapping slices so no content is lost at the cut lines. OpenAI GPT-5.4 reads the images and text, function calling constrains the output to a predefined JSON schema, and that validated JSON is written directly to DynamoDB as a structured record.
How did accuracy improve from 80% to 95%?
Through a monthly iteration loop rather than model retraining. We built a measurement harness that showed exactly which document formats and fields were failing, then refined prompts, added per-format extraction templates, mined few-shot examples from human-corrected documents, and tuned confidence thresholds. Each cycle raised accuracy as volume scaled from 10,000 to 100,000+ documents a month.
What happens when the AI is not confident about a document?
Every extraction carries a confidence score derived from schema validation and cross-field consistency checks—for example, line items must sum to document totals and dates must parse to valid billing periods. Results above the threshold flow straight into DynamoDB with no human involvement. Low-confidence documents are routed to a human review queue, and reviewer corrections are fed back into the pipeline as few-shot examples—so the same mistake becomes less likely over time. Documents that fail processing entirely go to a dead-letter queue for investigation instead of being lost.
How long did the project take and what team was required?
Four months with a team of four AI engineers. The first month delivered a working pilot processing 10,000 real documents at 80% accuracy. The following months were spent scaling volume and running the accuracy iteration loop until the pipeline handled the client's full load of 100,000+ documents a month at 95% accuracy.