# Adarsh Mamgain — document AI engineer, founder of Parse My Statement > I build production document extraction systems — OCR pipelines, self-hosted vision models, and RAG. Parse My Statement is the reference implementation, benchmarked against hand-written ground truth. Source: https://parsemystatement.com/about Updated: 2026-09-17 I am an independent engineer who builds document extraction systems and the measurement infrastructure that proves they work. Parse My Statement is my own product and the reference implementation of the architecture I build for clients — which means you can inspect the engineering before you hire me for it. **At a glance** - Production document AI, not slideware - Everything measured against hand-written ground truth - Independent — no vendor commissions or reseller margins - You work with the engineer who writes the code ## What I do I build systems that turn documents into data reliably enough to put in front of a regulator, a lender, or a ledger. In practice that means OCR and extraction pipelines, self-hosted vision and language models for teams whose data cannot leave their network, and retrieval systems over document corpora. The thread running through all of it is measurement. Most document AI work fails not because the models are inadequate but because nobody is scoring the output against known-correct values, so improvements and regressions are indistinguishable. Every project I take on starts by building the ground truth, because without it every subsequent decision is a guess with confidence attached. I work as a single engineer, directly with your team. There is no account manager, no delivery layer, and no junior doing the work under a senior's name. ## Parse My Statement as the reference implementation Rather than describe an approach, I run one in production. Parse My Statement converts bank statement PDFs into CSV, Excel, and JSON, and it is built on exactly the architecture I deploy for clients: a native-text fast path for digital PDFs, OCR with block-level confidence for scanned pages, optional vision-model escalation on low-confidence pages, LLM normalization into a strict schema, sign reconciliation from running balances, and an arithmetic balance check on every conversion. Its accuracy is published and measured, not asserted. The current engine scores 0.93 mean transaction F1 and 0.99 date accuracy against hand-written ground truth derived from real statements — Canara savings, HSBC savings, and ICICI credit card — reaching perfect F1 on two of the three. The version history on the benchmark includes a significant regression, because that is what an honest benchmark looks like. The whole system is there to be inspected: a public developer API, an MCP server, an evaluation harness, and a security page that declines to claim certifications it does not hold. ## How I prefer to work ### Measurement before building Ground truth and a scored baseline come first. If we cannot define what correct looks like, we cannot tell whether the project succeeded, and neither can you. ### Your repository from week one Code lands in your repo as it is written, reviewed by your team. No black-box delivery, no big reveal at the end. ### Honest ceilings Some documents cannot be extracted reliably by any system available today. I will tell you which of yours those are and design a review path for them rather than promise a number I cannot hit. ### Small scope, real deadlines Fixed-scope phases with deliverables you can evaluate. If an audit answers your question and you do not need the build, that is a good outcome. ## Things I have built - A production bank statement extraction engine with a ground-truth benchmark harness and CI accuracy gate - A hybrid OCR pipeline routing pages between native text, OCR, and vision models by measured confidence - A developer API and MCP server over the same pipeline, with key management, quotas, and usage logging - Arithmetic validation layers that catch extraction errors confidence scores do not report - Evaluation tooling with per-document postmortems that show precisely why a prediction missed its ground truth - Several other independent SaaS products, shipped and operated solo ## Frequently asked questions ### Are you available for new work? Usually yes, with a lead time of a few weeks. Short advisory engagements can often start sooner. The fastest way to find out is to describe the problem and the timeline you are working to. ### Do you work with startups or only enterprises? Both. Startups typically want an architecture review or a focused build that avoids a costly wrong turn; enterprises typically want accuracy, compliance, and on-premise deployment. The engineering underneath is the same. ### Do you work through agencies or as a subcontractor? Yes, where the working relationship with the end client's engineering team is direct. Extraction work goes badly when requirements pass through too many hands. ### Where are you based and how do you work with clients? Remote-first, working across European and North American time zones with overlap arranged per engagement. Async by default, with scheduled working sessions rather than standing meetings. ### What is the best way to reach you? Email adarsh@parsemystatement.com, or use the contact form. Include a document sample or a description of the problem and you will get a substantive reply rather than a calendar link. ## Tell me what you are trying to extract The most useful first message is a description of your documents and what you need out of them. I will tell you what is realistic — including when the answer is that you do not need me. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/services/document-ai-consulting - https://parsemystatement.com/licensing - https://parsemystatement.com/contact