Receipt & Document Intelligence Pipeline for Vault
Industry
Technologies
Country
Client Overview
Vault collects users' purchases from two sources. Paper receipts are scanned with the phone, and online order confirmations are forwarded to a personal address in the app. Both arrive unstructured and in every format UK retail produces: photos of thermal paper, HTML emails, PDF attachments. The platform we built turns those documents into clean, itemised purchase data. The pipeline reads documents with OCR tools, extracts and normalises every product line, discount, payment method, and loyalty detail, and categorises products into a coherent taxonomy. Receipts are the main document type, but the processing itself is general. Ingestion, extraction, normalisation, deduplication, and human review work the same way for any semi-structured document. The quality of this data determines the quality of the whole product, from the AI assistant to spending analytics, so reliability was the central requirement of the project.
Client Needs
Two ingestion channels: camera and email
Event-driven processing pipeline
Merchant and product unification
Analytics-ready purchase data
The pipeline had to accept whatever a user submits: a scanned receipt, an e-receipt, an order email with a PDF attachment. It needed to reliably extract individual line items, recognise that "TESCO STORES 3211" and "Tesco Extra" are the same merchant, map product descriptions to a common product catalogue, detect the same receipt submitted twice, and report failures with a clear reason instead of silently losing documents. All of it asynchronous, resistant to abuse, and ready to scale with the user base.
Services Provided
Two ingestion channels: Mobile scanning with on-device document detection and image enhancement, and email ingestion through personal forwarding addresses, with message bodies and attachments parsed into the same pipeline regardless of format.
Double extraction: Document data is extracted by two independent services, and a document counts as processed only when both results are in. This catches errors that a single engine would miss on low-quality documents.
Full processing history: The system records the outcome of every stage, so it is always clear what exactly happened to any given receipt or email. That makes finding the cause of a problem and tracing data during an audit much easier.
Merchant unification: Different spellings of the same shop on receipts are recognised and merged into a single merchant. Spending at one chain shows up together no matter how the store printed its name, and cross-store analytics builds on that.
Product unification: Line-item descriptions are mapped to a common product catalogue, enabling price comparison between stores and spending analytics.
Deduplication: The same receipt submitted twice is detected both within a single account and across the whole platform, with the duplicate's history kept for audit. This matters wherever purchase data is tied to rewards.
Operations console: An internal tool where the team reviews unmatched merchants, raw products, and problematic emails. Corrections flow back into the master data, so the pipeline improves with every reviewed case.
Abuse protection: Daily submission limits per user, file type and size restrictions, and per-stage processing caps keep the pipeline stable under hostile traffic.
Scope of Work
We designed and built the document processing platform end to end.
Designing the event-driven pipeline architecture: the orchestrator, the immutable record and snapshot model, and the Pub/Sub messaging between services.
Building the email ingestion path: personal forwarding addresses, message and attachment extraction, and matching incoming mail to the right user.
Implementing mobile receipt scanning with live edge detection, frame confidence scoring, and image enhancement tuned for receipt paper.
Building merchant unification with similarity matching and alias management, and product unification onto a common product catalogue.
Implementing user-level and platform-wide deduplication over receipt snapshots, with duplicate metadata preserved for audit.
Developing the internal operations console for human review of unmatched merchants, raw products, and failed emails.
Preparing the purchase data for Genie Vision, the B2B analytics product for retail chains, where the same data drives market analysis and campaigns.
Technologies Used
Development Process
We started with the documents themselves: before writing code, we agreed what a correctly processed receipt means and which errors are the most costly. Those criteria drove the architecture. We designed the pipeline around the assumption that input data cannot be trusted: every stage stores immutable records, every document carries its full processing history, and the failure paths received the same attention as the main flow. The operations console lets the team resolve unclear cases on their own, and their corrections keep improving the pipeline. The same pipeline now powers Genie Vision, a B2B analytics product for retail chains, where the same purchase data drives market analysis and campaign tools. It started as a prototype, moved to a production version, and is developed alongside the consumer side of the platform.
Check our work on Clutch