# Parse My Statement — full text > Upload bank statement PDFs or images and get clean, structured transactions in CSV, Excel, or JSON in seconds. Generated from the source content of https://parsemystatement.com/. Every page below is also reachable individually by appending `.md` to its URL. --- # Product summary Parse My Statement converts bank statement PDFs into normalized transactions as CSV, Excel, or JSON. Digital PDFs are read natively; scanned pages go through OCR with block-level confidence, and low-confidence pages can be re-verified by a vision-language model. An LLM normalization step produces a strict schema with typed dates, signed amounts, references, merchant classification, and per-transaction page attribution. Every conversion is balance-checked — opening plus credits minus debits equals closing — and previewed before download. Accuracy is measured with a ground-truth harness that scores every field against hand-written expected values taken from banks' own CSV exports. The current engine (v2.1) scores 0.93 mean transaction F1 and 0.99 date accuracy, reaching 1.00 F1 on two of three benchmark statements. ## Plans - **Free** — $0. Try the product before paying. Guest mode: 1-page uploads only. - **Pro 400** — $15 / month. For consistent monthly workflows. Up to 400 pages per month. - **Scale 1000** — $30 / month. For high-volume production usage. Up to 1000 pages per month. ## Product FAQ ### What file formats are supported? You can upload PDF bank statements. Guest mode supports single-page files. ### How accurate is the extraction? Our latest engine (v2.1, Aug 2026) scores 93% mean transaction F1 and 99% date extraction on hand-checked ground truth from real personal statements — Canara savings, HSBC savings, and ICICI credit card — reaching 100% F1 on two of the three. Every export is balance-checked (opening + credits − debits = closing) and previewed before download. ### How long are documents stored? Signed-in conversions are stored for 24 hours to support quick re-downloads, then removed automatically. ### Can I export to accounting tools? Yes. Download normalized CSV or Excel for spreadsheets and bookkeeping tools, or JSON for custom integrations. ### Do I need an account? No for quick trials. Create an account to process multi-page statements and access saved conversion history. --- # Document AI, OCR, and RAG engineering services > Custom OCR development, document parsing and extraction, self-hosted vision-language model deployment, RAG systems, on-premise deployment, and independent document AI consulting. Source: https://parsemystatement.com/services Updated: 2026-09-17 I build production document AI: OCR pipelines for documents that standard tools get wrong, extraction infrastructure with validation and human review, vision-language models running on your own hardware, and retrieval systems that are measured rather than hoped for. Parse My Statement is the reference implementation, so you can inspect the engineering before you hire me for it. **At a glance** - Accuracy measured against hand-written ground truth, never asserted - Delivered into your repository and your infrastructure - Independent engineer — no vendor commissions, no delivery layer - Fixed-scope phases, starting with an audit you can stop after ## The common thread: measurement Almost every document AI project I am called into has the same missing piece. There is a pipeline, there are models, there is a dashboard — and there is no ground truth. Nobody can say whether last month's change helped, because nothing is scored against known-correct values. That single gap explains most of what goes wrong downstream. Teams tune prompts when the problem is retrieval. They swap OCR vendors when the problem is normalization. They ship a model upgrade that quietly degrades accuracy for three weeks before anyone notices, because the only signal is user complaints. So every engagement I take starts the same way: build the ground truth, score the baseline, then make decisions against numbers. It is unglamorous and it is the reason these projects finish. ## How engagements are structured Fixed-scope phases. You can stop after any of them. ### 1. Audit or feasibility study One to three weeks, fixed price. A ground-truth set, a scored baseline, a cost and latency model, and a written recommendation. Some clients stop here because the report answers the question. ### 2. Build Four to twelve weeks. Iterative development against the benchmark, delivered into your repository from the first week, with accuracy visible at every step. ### 3. Hardening and handover Retries, timeouts, cost caps, observability, runbook, and training — plus the evaluation harness, so your team can keep scoring changes after I leave. ### 4. Retainer, if you want one Ongoing accuracy work as document mixes and models change. Entirely optional; the handover is designed so you do not need it. ## Typical reasons teams get in touch - Extraction accuracy has plateaued below what the business needs - A document AI pilot works in the demo and not in production - Compliance now requires that documents never leave the network - The LLM bill is growing faster than the volume that justifies it - A RAG system returns plausible answers from the wrong documents - An in-house build has stalled and nobody can say why - Statement parsing is needed in the product but not worth a team ## Frequently asked questions ### How do engagements usually start? With a fixed-price audit or feasibility study. It produces a ground-truth benchmark, a scored baseline, and a written recommendation you can execute with or without me. That structure exists so you can evaluate the work before committing to a build. ### Do you work as part of our engineering team? That is the preferred mode. I build in your repository, follow your conventions, and submit pull requests your engineers review — because the goal is that your team can extend the system after handover. ### What does this cost? Audits start around $1,400, builds around $3,500, and retainers around $1,800–$2,200 per month. Advisory time is $180 an hour. Each service page carries indicative ranges; final scope and price are fixed in writing after a discovery call. ### Can you work under our security and compliance requirements? Yes. NDA and DPA as standard, work inside your environment where required, and fully on-premise or air-gapped deployment where documents may not reach any third party. ## Start with the documents Send a sample of what you need extracted — ideally the cases that currently fail. You will get an honest read on what is achievable and what it would take. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/services/document-data-extraction - https://parsemystatement.com/services/self-hosted-vision-language-models - https://parsemystatement.com/services/rag-development --- # Custom OCR development for documents that off-the-shelf OCR gets wrong > Custom OCR pipeline development for scanned, photographed, and low-quality documents — layout-aware extraction, confidence scoring, vision-model escalation, and ground-truth accuracy benchmarks. Source: https://parsemystatement.com/services/custom-ocr-development Updated: 2026-09-17 Generic OCR reads characters. It does not read tables, reconcile columns, or tell you when it is guessing. I build production OCR pipelines that combine native text extraction, OCR with block-level confidence, vision-model escalation on low-confidence pages, and arithmetic validation — then prove the accuracy against hand-written ground truth instead of a vendor datasheet. **At a glance** - Layout-aware table extraction, not just character recognition - Per-page confidence scoring with automatic vision-model escalation - Ground-truth benchmark harness so accuracy is measured, not claimed - Runs on your cloud, your VPC, or fully on-premise ## Why standard OCR fails on real documents Most OCR products are benchmarked on clean, single-column, machine-printed pages. Real production documents are not that. They are faxed invoices, photographed receipts, multi-column bank statements, scanned shipping manifests with stamps across the table, and PDFs where the text layer disagrees with what is visually printed. The failure mode is rarely a misread character. It is a structural failure: two columns merged into one, a debit silently recorded as a credit, a continuation row attached to the wrong transaction, a total that no longer matches its line items. Those errors pass every spell-check and land straight in your database. The fix is not a better OCR vendor. It is a pipeline: route each page to the cheapest method that can read it, score how confident that read was, escalate only the pages that need a stronger model, and then validate the structured output against arithmetic the document itself must satisfy. ## What I build Every engagement is scoped to your document types, but these are the components that make up a production OCR system. ### Native-text fast path Digital PDFs never need OCR. A layout-preserving text extractor handles them in milliseconds at zero API cost, with column-header hints so a Debit/Credit/Balance grid survives extraction. Typically this alone routes 60–80% of a document corpus off the expensive path. ### OCR with block-level confidence Scanned and photographed pages go to an OCR model that returns positioned blocks and per-block confidence, not just a wall of text. Tables are preserved as structured HTML rather than flattened into prose, so column relationships survive. ### Vision-model escalation Pages whose confidence falls below a threshold are re-verified by a vision-language model against the rendered page image. Escalation is capped per document and fails safe, so a slow or unavailable model degrades quality gracefully instead of breaking the job. ### Structured normalization An LLM step converts raw text into a strict JSON schema — typed dates, signed amounts, references, per-field page attribution — using constrained JSON output and tolerant parsing so a single malformed response does not fail the document. ### Domain validation rules The step almost everyone skips. Running-balance reconciliation, line-items-sum-to-total checks, date monotonicity, sign inference from balance deltas, duplicate detection. These catch errors no confidence score will. ### Evaluation harness A repeatable benchmark that scores every field against hand-written ground truth and reports precision, recall, F1, latency, and cost per page. Without this you cannot tell an improvement from a regression. ## How an engagement runs Fixed scope, fixed milestones, and a measurable accuracy target agreed before any pipeline work starts. ### 1. Document audit (week 1) You send a representative sample — ideally 20–50 documents covering your worst cases, not your best. I categorise them by layout family, measure how many are digital versus scanned, and identify the specific structures that will break a naive extractor. ### 2. Ground truth and target accuracy (week 1–2) We hand-write ground truth for a held-out subset and agree what 'good enough' means in numbers: field-level F1, tolerance on amounts, acceptable manual-review rate. This becomes the acceptance criterion for the whole project. ### 3. Baseline and gap analysis (week 2) I run your documents through a baseline pipeline and score it. You get a written report of exactly where accuracy is lost, per document family, with the cost and latency profile of each stage. Some clients stop here — the report alone is often enough to redirect an in-house effort. ### 4. Pipeline build (weeks 3–8) Iterative build against the benchmark. Every change is scored before and after, so progress is visible rather than asserted. You get working code in your repository from the first week, not a demo at the end. ### 5. Hardening and handover Retries, timeouts, concurrency limits, cost caps, structured logging, failure-mode documentation, and a runbook. Plus the benchmark harness itself, so your team can keep scoring changes after I am gone. ## Document types this pipeline suits - Bank statements — retail, business, and credit card, across multiple countries and layout conventions (the type I have taken furthest, in production) - Invoices and purchase orders with variable line-item tables - Receipts, including phone-camera captures with skew, glare, and creasing - Financial reports and statements of account with nested subtotals - Identity and KYC documents with mixed print and handwriting - Logistics paperwork — manifests, bills of lading, delivery notes - Forms with checkbox, signature, and free-text regions ## Accuracy on my own production benchmark Parse My Statement is the reference implementation of this pipeline. These scores come from the same ground-truth harness I build for clients, run against real personal statements (Canara savings, HSBC savings, ICICI credit card) scored field by field against the banks' own CSV exports. | Engine version | Transaction F1 | Date accuracy | Notes | | --- | --- | --- | --- | | v2.1 · Aug 2026 | 0.93 | 0.99 | Vision escalation + table-header hints; 100% F1 on two of three statements | | v2.0 · Jul 2026 | 0.48 | 0.66 | Blocks + confidence, before normalization hardening — a measured regression | | v1.1 · Jun 2026 | 0.90 | 1.00 | OCR-only path | | v1.0 · Mar 2026 | 0.86 | 0.99 | First production release | ## Engagement options Indicative ranges. Final scope and price depend on document variety, volume, and how much of the infrastructure already exists. ### Extraction audit — from $1,400 (1–2 weeks) A written accuracy and feasibility report on your document corpus, with a baseline benchmark you keep. - Document corpus categorisation - Ground-truth set for a held-out sample - Scored baseline with per-family failure analysis - Cost and latency model per page - Build-versus-buy recommendation ### Pipeline build — from $3,500 (4–10 weeks) A production extraction pipeline for one or more document families, delivered into your repository. - Everything in the audit - Full pipeline: routing, OCR, escalation, normalization, validation - Evaluation harness and CI accuracy gate - Deployment to your cloud, VPC, or on-premise hardware - Runbook, failure-mode docs, and team handover ### Retained engineering — from $2,200 / month (Rolling, 3-month minimum) Ongoing accuracy work as your document mix changes and new sources come online. - New document families added on a rolling basis - Regression monitoring against the benchmark - Model and cost optimisation as providers change - Priority response on extraction incidents ## Frequently asked questions ### Can you improve an OCR pipeline we already have? Yes, and it is often the faster path. The first step is the same either way: build a ground-truth benchmark so we can see where accuracy is actually being lost. In many cases the existing pipeline is sound and the problem is in normalization or missing validation rules, which is a much smaller fix than a rebuild. ### Which OCR and vision models do you use? It depends on the documents and your constraints. Parse My Statement runs Mistral OCR for scanned pages and Qwen3-VL for vision re-verification, with DeepSeek for normalization. For clients who cannot send data to third-party APIs I build the same architecture on self-hosted models — see the self-hosted vision-language model service. ### How accurate can you actually get? That depends entirely on the documents, and any consultant who quotes a number before seeing yours is guessing. What I commit to is a measured baseline in the first two weeks and a target agreed in writing against that baseline. Clean digital documents routinely reach near-perfect field accuracy; degraded phone photos of handwritten forms will not, and the honest answer is to design a human-review queue for them. ### Do you hand over the source code? Yes. Work is delivered into your repository under your ownership as it is written, not at the end. The evaluation harness comes with it so your team can keep measuring after handover. ### Can this run without sending data to any external API? Yes. The same architecture runs on self-hosted OCR and vision models inside your own network or an air-gapped environment. That changes the hardware requirements and usually the accuracy ceiling, and both are quantified during the audit. ## Send me your hardest documents The fastest way to start is a sample of the documents that currently break. I will tell you what is realistically achievable and what it would take — before any engagement is signed. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/document-data-extraction - https://parsemystatement.com/services/self-hosted-vision-language-models - https://parsemystatement.com/services/on-premise-deployment - https://parsemystatement.com/licensing --- # Document parsing and data extraction, built as production infrastructure > Turn unstructured PDFs, scans, and emails into validated structured data. Custom document parsing pipelines with schema design, confidence scoring, human review queues, and measurable accuracy. Source: https://parsemystatement.com/services/document-data-extraction Updated: 2026-09-17 Most document-extraction projects fail at the boundaries, not the model: no agreed schema, no validation, no confidence threshold, no plan for the 5% of documents that will always need a human. I design and build the whole path — ingestion, extraction, validation, review queue, and the API your product actually calls — with accuracy measured against ground truth at every step. **At a glance** - Schema design first, so downstream systems get a stable contract - Confidence thresholds and human-review queues for the long tail - Idempotent, retryable pipelines that survive provider outages - Delivered as an API your product can call, not a notebook ## The part nobody scopes Extraction demos are easy. You pick three clean documents, prompt a capable model, and the output looks perfect. The project then stalls for six months on everything that demo skipped. What it skipped: what the output schema is and who owns it when it changes. What happens when the model returns nine fields instead of ten. How a document that scored 0.4 confidence gets in front of a human without blocking the queue. What the per-document cost is at 100,000 documents a month and whether that is still viable. How you know next month's model upgrade did not silently make things worse. I build for those questions from day one, because they are what determines whether an extraction system reaches production or quietly gets shelved. ## What the build includes ### Schema and contract design A typed output schema, versioned, with explicit nullability and units. Downstream teams get a stable contract and a documented migration path when fields change. ### Ingestion and routing Email, SFTP, S3, webhook, or direct upload. Deduplication, virus scanning, page splitting for multi-document files, and classification so each document reaches the right extractor. ### Extraction and normalization The right method per document family — native text, OCR, vision model, or a layout model — followed by a normalization step that produces the agreed schema with per-field confidence. ### Validation and reconciliation Domain rules that catch what confidence scores miss: totals that must sum, dates that must fall in range, cross-field consistency, running-balance checks, and duplicate detection across documents. ### Human-in-the-loop review A review queue fed by confidence thresholds and failed validations, with side-by-side document and field editing. Corrections are captured as new ground truth, so the benchmark improves as the system runs. ### Delivery API A documented HTTP API — async upload, status polling, result fetch — plus optional MCP server so AI agents can call the same pipeline. Keys, quotas, rate limits, and per-key usage logs included. ## The path to production ### 1. Schema workshop We define exactly what fields you need, their types, and which are strictly required. This is the single highest-leverage hour in the project and it happens before any code. ### 2. Ground truth and baseline A hand-written ground-truth set from your real documents, and a first scored run. Now every later decision is measurable. ### 3. Pipeline build Routing, extraction, normalization, validation, storage. Built iteratively against the benchmark, in your repository, visible from week one. ### 4. Review queue and thresholds We tune the confidence threshold against your actual tolerance: how many documents you are willing to review by hand versus how many errors you are willing to let through. That trade-off is a business decision and I make it explicit rather than picking a number for you. ### 5. Load, cost, and handover Throughput testing at your target volume, a per-document cost model, structured logging and alerting, and a runbook your on-call team can actually use. ## Where documents typically come from | Source | Typical challenge | How it is handled | | --- | --- | --- | | Customer email attachments | Mixed formats, multiple documents per PDF | Classification and page-level splitting before extraction | | Bank and card portals | Column layouts that differ per institution | Layout-aware extraction with per-bank profiles | | Supplier invoices | Variable line-item tables, multi-page continuations | Table-structure extraction with total reconciliation | | Phone photos from field staff | Skew, glare, partial captures | Image preprocessing, vision escalation, review queue | | Legacy scanned archives | Degraded quality, inconsistent scanning | Batch reprocessing with per-page confidence triage | | Third-party APIs | Schema drift without notice | Contract validation with alerting on unexpected shapes | ## Engagement options Indicative ranges; scope is fixed in writing after the discovery call. ### Discovery & architecture — from $1,400 (1–2 weeks) Schema design, document analysis, and a written architecture plus cost model you can build against — with or without me. - Output schema definition - Document corpus analysis - Reference architecture and provider comparison - Per-document cost and latency model - Delivery plan with milestones ### Production pipeline — from $3,500 (4–12 weeks) End-to-end extraction infrastructure delivered into your stack and running on your volume. - Ingestion, extraction, validation, storage - Confidence-driven human review queue - Documented API and optional MCP server - Evaluation harness and CI accuracy gate - Load testing, runbook, and handover ### Managed extraction — from $2,200 / month (Rolling, 3-month minimum) I run and improve the pipeline so your team does not have to hire for it. - New document families onboarded continuously - Accuracy and cost monitoring with monthly reporting - Provider and model migration handled - Priority incident response ## Frequently asked questions ### We already use an IDP vendor. Is this a replacement? Not necessarily. Sometimes the right answer is to keep the vendor and build the validation, routing, and review layers around it — that is a cheaper project with most of the accuracy gain. The audit tells us which. I have no incentive to recommend a rebuild you do not need. ### What volume does this handle? The architecture is queue-based and horizontally scalable; throughput is a function of worker count and provider rate limits rather than a fixed ceiling. Load testing at your target volume is part of the build, and the cost model is produced before you commit to it. ### Can you work with our existing engineering team? That is the preferred mode. I build in your repository, against your conventions, with your team reviewing pull requests. The goal is that your engineers can extend the pipeline after handover, which does not happen if I build it in isolation. ### What about documents in languages other than English? Multilingual extraction is supported by the OCR and vision models used, but accuracy varies significantly by language and script. If non-English documents are a meaningful share of your corpus, they go into the ground-truth set so the number is measured rather than assumed. ### How do you handle sensitive documents during the engagement? Under a signed NDA and DPA, with the option to work entirely inside your environment so no document ever leaves your infrastructure. For highly sensitive corpora I work from redacted or synthetic samples for development and validate against real data only inside your network. ## Start with the schema, not the model Tell me what fields you need and what your documents look like. I will come back with an architecture, a cost model, and an honest view on whether this is a four-week project or a four-month one. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/services/rag-development - https://parsemystatement.com/services/document-ai-consulting - https://parsemystatement.com/white-label --- # Deploy vision-language models on your own hardware > Set up open-weight vision-language and OCR models on your own GPUs or private cloud — Qwen3-VL, InternVL, and similar. Sizing, quantization, vLLM serving, throughput tuning, and accuracy validation. Source: https://parsemystatement.com/services/self-hosted-vision-language-models Updated: 2026-09-17 If your documents cannot leave your network — regulation, contract, or policy — you need open-weight vision and OCR models running on hardware you control. I size the hardware, pick and quantize the models, stand up the inference server, tune it for your throughput, and validate that the accuracy you get locally is actually acceptable for the job. **At a glance** - Honest hardware sizing before you buy a single GPU - Model selection validated on your documents, not on public leaderboards - vLLM / TensorRT-LLM serving with batching and concurrency tuned to your load - Works air-gapped, in your VPC, or on a single on-prem workstation ## The question that comes before the GPU order The most expensive mistake in self-hosted AI is buying hardware before validating that an open-weight model can do the job at all. The failure runs both ways: capacity bought for a workload a quantized mid-size model on a single card would have served, or a model chosen for the hardware budget rather than the task, with the shortfall discovered months later. Either way the money is spent before the question is answered. So the engagement starts backwards from the hardware. First: can an open-weight model hit your accuracy target on your documents? Second: at what quantization does it still hit it? Third: what throughput do you need, and what does that imply for VRAM, card count, and concurrency? Only then does anyone place an order. That sequence usually saves more than the engagement costs, and occasionally the answer is that self-hosting is not worth it for your workload — which is also a useful result to have in writing. ## What the deployment covers ### Model selection and evaluation Candidate open-weight vision and OCR models scored on your documents against ground truth — not on public benchmarks that do not resemble your corpus. You get the comparison table and the reasoning behind the pick. ### Quantization and accuracy trade-off FP16, FP8, AWQ, GPTQ, and GGUF variants scored so you can see exactly what accuracy you give up for what VRAM saving. This is measured per model, not assumed from general guidance. ### Hardware sizing A concrete specification: card model, count, VRAM, host memory, storage throughput, and network. Sized against your measured peak load rather than a vendor's marketing throughput figure. ### Inference serving vLLM or TensorRT-LLM configured for your workload — continuous batching, KV cache sizing, tensor parallelism, prefix caching where it helps — behind an OpenAI-compatible endpoint your existing code can call with a URL change. ### Throughput and latency tuning Benchmarked concurrency curves so you know your real pages-per-second and p95 latency, plus the queueing configuration to keep latency stable under burst. ### Operations Containerised deployment, health checks, GPU and queue metrics, model-update procedure, and a rollback path. Air-gapped installs get an offline artifact bundle. ## How it runs ### 1. Feasibility evaluation Your documents, a ground-truth set, and three to five candidate open-weight models scored head to head — including against whatever hosted API you would otherwise use, so the accuracy gap is explicit. ### 2. Sizing report A written hardware specification with cost, based on the winning model, its quantization, and your measured throughput requirement. Includes the cloud-GPU equivalent so you can compare buy versus rent honestly. ### 3. Deployment Inference server stood up on your hardware, integrated behind an OpenAI-compatible endpoint, with your application switched over and running. ### 4. Tuning and validation Load testing to your peak, concurrency and batching tuned, and a final accuracy run confirming the deployed system matches the evaluation scores. ### 5. Handover Runbook, monitoring dashboards, model-upgrade procedure, and a training session with your infrastructure team. ## Typical deployment shapes Indicative starting points. Actual sizing always comes from the evaluation, because it depends on model choice, quantization, and your concurrency. | Scenario | Typical shape | What it suits | | --- | --- | --- | | Single-workstation pilot | One 48GB-class card, quantized mid-size VLM | Proving the workflow before capital spend | | Departmental production | 2–4 cards, batched serving, queue in front | Steady internal document volume with burst tolerance | | High-throughput pipeline | Multi-node, tensor parallel, autoscaled workers | Continuous ingestion at scale | | Air-gapped / classified | Offline artifact bundle, no external network path | Environments where no egress is permitted | | Private cloud (VPC) | Managed GPU instances in your own account | Data-residency requirements without owning hardware | ## You should consider self-hosting if - Regulation or client contracts prohibit sending documents to third-party APIs - Your data-residency requirements are not met by available API regions - Per-document API cost at your volume now exceeds amortised hardware cost - You need deterministic model versions that do not change under you - Latency requirements rule out a round trip to an external provider - You already own idle GPU capacity and want to use it ## Engagement options ### Feasibility & sizing — from $1,800 (2–3 weeks) Find out whether self-hosting works for your workload — and what it would cost — before committing to hardware. - Ground-truth set from your documents - 3–5 open-weight models scored head to head - Quantization accuracy trade-off table - Hardware specification with cost - Buy-versus-rent comparison ### Full deployment — from $3,000 (3–8 weeks) Models running in production on your hardware, integrated with your application. - Everything in feasibility & sizing - vLLM / TensorRT-LLM serving setup - OpenAI-compatible endpoint integration - Throughput and latency tuning - Monitoring, runbook, and team training ### Ongoing operation — from $1,800 / month (Rolling) Model upgrades, capacity planning, and performance work as your volume grows. - Model evaluation and upgrade as new weights release - Capacity planning against observed growth - Performance regression monitoring - Priority support on inference incidents ## Frequently asked questions ### Which models do you deploy? Open-weight vision-language models in the Qwen-VL and InternVL families, open OCR models, and open text models for the normalization step. The specific pick comes out of the evaluation on your documents — model rankings change every few months and a recommendation made without measuring yours is worth very little. ### Will self-hosted accuracy match a frontier API? Sometimes, and sometimes not. On structured document extraction the gap is often smaller than people expect, especially once domain validation rules are layered on top. The evaluation gives you the actual number for your documents so the decision is made on data. If the gap is unacceptable I will tell you that. ### Can you work with hardware we already own? Yes. If you have existing GPU capacity the evaluation targets it directly, and the sizing report tells you whether it is sufficient, needs augmenting, or is genuinely the wrong shape for the workload. ### Do you support fully air-gapped environments? Yes. Deliverables include an offline artifact bundle — model weights, container images, and dependencies — with an installation procedure that requires no external network access. Access arrangements for the install itself are agreed per engagement. ### What ongoing maintenance does this need? Less than most teams fear, but not zero. Realistically: GPU driver and container updates, monitoring, and a model evaluation every few months as better open weights release. That is a few days a quarter for a competent infrastructure engineer, or a retainer if you would rather not own it. ## Find out if self-hosting is viable before you buy hardware Send me a sample of your documents and your throughput requirement. The feasibility evaluation answers the question with numbers, and it is scoped so you can stop there if the answer is no. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/on-premise-deployment - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/services/rag-development - https://parsemystatement.com/enterprise --- # RAG systems that retrieve the right thing — and prove it > Design, build, and evaluate retrieval-augmented generation systems: chunking and indexing strategy, hybrid and reranked retrieval, grounded answer generation, and retrieval evaluation harnesses. Source: https://parsemystatement.com/services/rag-development Updated: 2026-09-17 Nearly every failing RAG system fails at retrieval, not generation — and almost none of them are measuring retrieval separately, so nobody knows. I build RAG systems where ingestion, chunking, retrieval, and generation are each independently evaluated, so when quality drops you know exactly which stage caused it. **At a glance** - Retrieval measured on its own: recall@k, MRR, nDCG — before touching prompts - Document-aware ingestion, because most RAG corpora start as PDFs - Hybrid search with reranking, not naive top-k cosine similarity - Grounded answers with citations and refusal behaviour when evidence is missing ## Why RAG pilots stall A RAG demo takes an afternoon: embed some documents, do a similarity search, stuff the results into a prompt. It works impressively on the ten questions you thought of while building it, and then it goes to real users and the answers get vague, confidently wrong, or cite the wrong page. The debugging then goes in the wrong direction. Teams tune prompts, swap models, raise the temperature, add more context — all downstream of the actual problem, which is almost always that the correct passage never made it into the context window at all. No prompt can fix a retrieval miss. The discipline that fixes this is unglamorous: evaluate retrieval independently of generation. Build a question set with known correct source passages. Measure recall@k. Get that number high first. Only then is it worth tuning anything about the prompt. ## What I build ### Document-aware ingestion Most knowledge bases arrive as PDFs, scans, and exported wiki pages. Getting clean, structure-preserving text — tables intact, headers attached to their sections — is where retrieval quality is won or lost. This is the same extraction work as my OCR practice, pointed at a different outcome. ### Chunking strategy Chunk size, overlap, and boundary rules tuned against your evaluation set rather than copied from a tutorial. Structural chunking that respects section and table boundaries, with parent-document retrieval where small chunks retrieve but large context answers. ### Hybrid retrieval Dense vectors for semantic similarity plus BM25 for exact terms — identifiers, product codes, names — that embeddings reliably lose. Fused and then reranked with a cross-encoder, which is usually the single largest quality jump available. ### Metadata and filtering Per-chunk metadata for date, source, department, and permission scope, so retrieval can be filtered before ranking. This is also how multi-tenant and access-controlled RAG stays correct. ### Grounded generation Answers with inline citations to source passages, and explicit refusal when retrieved evidence does not support an answer. A system that says 'not found in the documents' is worth far more than one that guesses plausibly. ### Evaluation harness Separate scoring for retrieval (recall@k, MRR, nDCG) and answers (groundedness, correctness, citation accuracy), runnable in CI so a model or index change cannot silently regress quality. ## How the build runs ### 1. Question set and ground truth Real questions from real users, each annotated with the passages that actually answer them. Fifty to a hundred is usually enough to drive every decision that follows. This comes before any index is built. ### 2. Ingestion and indexing Document extraction, chunking, embedding, and index construction — with the chunking strategy chosen by scoring two or three options against the question set rather than by preference. ### 3. Retrieval tuning Hybrid weighting, reranking, and filter design, iterated until recall@k plateaus. This is where most of the quality comes from and where most of the engagement time goes. ### 4. Generation and guardrails Answer synthesis with citations, refusal behaviour, and prompt-injection handling for untrusted document content — which matters a great deal once your corpus includes anything user-submitted. ### 5. Production hardening Incremental re-indexing as documents change, cost and latency budgets, caching, observability on retrieval quality in production, and a feedback path that turns user corrections into new evaluation cases. ## Common failure modes and what actually fixes them | Symptom | Usual root cause | Fix | | --- | --- | --- | | Answers are vague and generic | Correct passage never retrieved | Measure recall@k; fix chunking and add reranking | | Exact IDs or codes are never found | Pure vector search loses rare tokens | Add BM25 and fuse the result sets | | Confident but wrong answers | No grounding constraint or refusal path | Citation-required generation with explicit refusal | | Good on old docs, wrong on new | Stale index, no incremental re-ingestion | Change-detection pipeline with scheduled re-indexing | | Quality dropped after a model change | No regression testing on retrieval | Evaluation harness in CI with a quality gate | | Users see documents they should not | Permissions applied after retrieval | Permission-scoped metadata filtering before ranking | ## Engagement options ### RAG audit — from $1,400 (1–2 weeks) For teams with a RAG system that underperforms and no clear picture of why. - Evaluation set built from your real questions - Retrieval scored independently of generation - Root-cause analysis with ranked fixes by impact - Cost and latency profile - Written remediation plan ### RAG build — from $3,500 (4–10 weeks) A production retrieval system over your corpus, with evaluation built in from the start. - Document ingestion including PDFs and scans - Chunking, hybrid retrieval, and reranking tuned to your data - Grounded generation with citations and refusal - Evaluation harness wired into CI - Deployment, observability, and handover ### Ongoing RAG engineering — from $2,200 / month (Rolling, 3-month minimum) Continuous quality work as your corpus, questions, and models change. - New sources onboarded - Evaluation set grown from production feedback - Model and embedding migrations handled - Monthly quality and cost reporting ## Frequently asked questions ### Which vector database should we use? For most corpora it matters far less than teams expect. Postgres with pgvector handles a surprising amount of production RAG perfectly well and removes an entire piece of infrastructure. Dedicated vector databases earn their place at large scale or with demanding filtering requirements. I will recommend based on your corpus size, filtering needs, and what your team already operates — not on what is currently fashionable. ### Can this run entirely on self-hosted models? Yes — embeddings, reranker, and generation model can all be open-weight and self-hosted. That pairs naturally with the self-hosted vision-language model service if your documents also cannot leave your network. ### Do we need fine-tuning? Usually not, and it is rarely the first thing to try. Retrieval quality and prompt structure account for most of the achievable gain; fine-tuning is worth considering for domain-specific output formatting or a specialised reranker once retrieval is already strong. I will tell you if your case is one of the exceptions. ### How do you handle documents with tables and figures? With the same structure-preserving extraction I use for document parsing — tables kept as structured markup rather than flattened into prose, and figures captioned via a vision model so they become retrievable. Corpora heavy in tables are exactly where naive ingestion pipelines lose the most. ### What about prompt injection from documents in the corpus? Treated as a real threat, not a footnote. Retrieved content is delimited and handled as untrusted data, tool-calling surfaces are constrained, and instruction-like content in documents is neutralised. This matters most when any part of the corpus is user-submitted. ## Start by measuring retrieval If your RAG system is underperforming, the audit will tell you within two weeks whether the problem is ingestion, chunking, retrieval, or generation — with numbers rather than intuition. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/document-data-extraction - https://parsemystatement.com/services/self-hosted-vision-language-models - https://parsemystatement.com/services/document-ai-consulting - https://parsemystatement.com/services/custom-ocr-development --- # Document AI consulting: architecture, build-versus-buy, and accuracy strategy > Independent consulting on document AI architecture, model and vendor selection, accuracy measurement, cost modelling, and build-versus-buy decisions — from an engineer who ships extraction systems. Source: https://parsemystatement.com/services/document-ai-consulting Updated: 2026-09-17 Independent advisory for teams making expensive, hard-to-reverse decisions about document AI: which architecture, which models, build or buy, what it will really cost at volume, and how to know whether it is working. I am an engineer who ships these systems, not a reseller — I have no vendor relationships to protect. **At a glance** - No vendor commissions, reseller margins, or partner incentives - Recommendations grounded in measurements on your documents - Written deliverables your team and your board can act on - Available as a fixed-scope review or an ongoing fractional role ## What advisory work looks like Three situations it fits. A team has built a document AI feature that works in the demo and not in production, and needs to know whether to fix it or restart. A team is about to commit to a vendor or an architecture and wants an independent read before signing. Or an investor needs technical diligence on a company whose core claim is extraction accuracy. In all three the valuable output is the same: a clear, written, measured answer that someone can act on. Not a slide deck of industry trends. I work as an engineer throughout. If a question can be settled by running your documents through three pipelines and scoring the results, I will run them rather than reason about it. ## Advisory areas ### Architecture review Your current or planned document AI architecture assessed for accuracy ceiling, failure modes, cost at projected volume, and operational risk — with specific, prioritised changes rather than general principles. ### Build versus buy An honest comparison of commercial IDP vendors, hosted model APIs, and a custom build for your specific corpus, including the total cost of ownership that vendor pricing pages leave out. ### Model and vendor selection Candidate models and vendors scored on your documents against ground truth. Public benchmarks rarely predict performance on a specific corpus; this replaces that guesswork with measurement. ### Accuracy strategy Defining what accuracy means for your use case, building the ground-truth set, choosing the metrics that reflect business impact, and setting the confidence thresholds that govern human review. ### Cost and unit economics Per-document cost modelling across extraction methods and providers, with the routing strategy that keeps the expensive path rare. This frequently pays for the engagement several times over. ### Technical due diligence For investors and acquirers: independent assessment of whether an AI extraction company's accuracy claims survive contact with a ground-truth benchmark, and how defensible the underlying engineering actually is. ## How to engage ### Advisory call — $180 / hour (Same or next week) A focused working session on a specific decision, with written notes afterwards. - 60–90 minutes, screen-shared and working - Reviewed materials in advance - Written summary and recommendations - No minimum commitment ### Written review — from $1,400 (1–2 weeks) A fixed-scope assessment with a document your team can build against and your leadership can read. - Architecture, vendor, or diligence review - Measured comparison on your documents where relevant - Prioritised recommendations with effort estimates - Cost model at your projected volume - Follow-up session to work through it ### Fractional AI engineer — from $1,800 / month (Rolling, 2-month minimum) Ongoing technical leadership for teams building document AI without a senior specialist in house. - Regular working sessions with your engineers - Design review on extraction and retrieval work - Hands-on contribution where it unblocks fastest - Hiring support for AI engineering roles ## Questions this work answers - Should we build this ourselves or buy an IDP vendor? - Our extraction is 85% accurate and the business needs 98% — is that reachable? - Our LLM bill is growing faster than revenue. Where is the waste? - Is our RAG system underperforming because of retrieval or generation? - Can we run this on our own hardware for compliance reasons? - This vendor claims 99% accuracy. How do we verify that? - We are acquiring a document AI company. Is the technology real? ## Frequently asked questions ### Do you take commissions from vendors you recommend? No. I have no reseller agreements, referral fees, or partner commissions with any AI provider. That independence is the point of hiring an engineer rather than a systems integrator. ### Can you review work done by another vendor or agency? Yes. The review is on the engineering and the measured results, not on the people. Where the existing work is sound I will say so — I would rather hand back a short report saying the build is fine than manufacture a problem. ### Do you sign NDAs? Yes, as a matter of course, before any materials are shared. For diligence engagements I will also confirm I have no conflicting engagement with the target or a direct competitor. ### What do you need from us to start? A representative document sample, a description of the current or planned architecture, and a clear statement of the decision you are trying to make. If a ground-truth comparison is part of the scope, expected outputs for a subset of documents as well. ### Can an advisory engagement turn into a build? Often it does, but the advisory deliverable is written to stand alone and to be executable by your own team or another vendor. Recommending work for myself is exactly the bias that makes most consulting worthless. ## Bring me the decision, not the project Tell me what you are choosing between and what evidence you have so far. If an hour will settle it, I will say so rather than propose an engagement. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/document-data-extraction - https://parsemystatement.com/services/rag-development - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/licensing --- # On-premise and private-cloud document AI deployment > Deploy the full document extraction stack inside your own infrastructure — VPC, private cloud, or air-gapped — with no document leaving your network. Sizing, deployment, and compliance documentation. Source: https://parsemystatement.com/services/on-premise-deployment Updated: 2026-09-17 Some documents cannot leave your network — banking supervision, healthcare rules, government classification, or a client contract that simply forbids it. I deploy the entire extraction stack, from OCR through normalization to the API your product calls, inside your own infrastructure, with the compliance documentation your auditors will ask for. **At a glance** - Nothing leaves your network: models, queue, storage, and API all inside your perimeter - Kubernetes, Docker Compose, or bare metal — whatever your operations team runs - Air-gapped installation with an offline artifact bundle - Architecture and data-flow documentation written for auditors ## When the API is not an option A hosted extraction API is the right answer for most teams most of the time. It stops being the right answer the moment a regulator, a supervisory authority, or a client contract says that customer documents may not be transmitted to a third-party processor. At that point teams usually discover that 'self-hosted' in the AI tooling world often means 'self-hosted application, hosted models' — which does not satisfy the requirement at all, because the documents still reach an external inference provider. This service deploys the whole path inside your perimeter: OCR models, vision models, the normalization model, the queue, the object storage, and the API surface. The only network traffic leaving your environment is whatever you explicitly choose to allow. ## What gets deployed ### Inference layer Open-weight OCR, vision, and text models served on your GPUs behind an internal OpenAI-compatible endpoint. Sized from a measured evaluation, not a guess. ### Processing pipeline Ingestion, page routing, extraction, normalization, validation, and export — as containerised workers scaled to your document volume. ### Queue and storage Your Redis or equivalent for job orchestration, your Postgres and object storage for documents and results, with retention policies configured to your own rules. ### API and integration surface A documented internal HTTP API, optional MCP server for agent access, and API-key management with per-key quotas and usage logs. ### Observability Structured logging, processing metrics, GPU and queue dashboards, and alerting wired into whatever your operations team already uses. ### Compliance pack Architecture diagram, data-flow map, retention matrix, processing-activity description, and a statement of exactly which components touch document content. Written to be handed to an auditor. ## Deployment path ### 1. Environment and constraint review What you run, what your network policy permits, what your auditors require, what hardware exists. Constraints first, because they determine everything downstream. ### 2. Model evaluation and sizing Open-weight models scored on your documents, hardware specified against your throughput. Detailed in the self-hosted vision-language model service, and included here. ### 3. Staged deployment Non-production environment first, with your team present throughout so the deployment is understood rather than delivered as a black box. ### 4. Integration and validation Your application switched onto the internal endpoint, load tested at peak, and accuracy re-validated against the benchmark in its final deployed configuration. ### 5. Compliance documentation and handover The audit pack, the runbook, the upgrade procedure, and training for the team who will own it. ## Deployment targets | Target | Notes | | --- | --- | | Kubernetes (on-prem or managed) | Helm chart, HPA on queue depth, GPU node pools | | Docker Compose on bare metal | Simplest option for single-node departmental deployments | | AWS / GCP / Azure in your own account | Your VPC, your keys, your region — satisfies most data-residency rules | | Air-gapped datacentre | Offline artifact bundle; no external network path at any stage | | Hybrid | Sensitive documents processed internally, non-sensitive routed to hosted APIs for cost | ## Included in every on-premise engagement - Infrastructure-as-code for the full stack, in your repository - Hardware sizing report with headroom for projected growth - Accuracy validation in the final deployed configuration, not just in staging - Backup, restore, and disaster-recovery procedure - Model and application upgrade path with rollback - Compliance and data-flow documentation - Operations runbook and live training session ## Frequently asked questions ### Is this the same engine that runs Parse My Statement? The architecture is the same and much of the pipeline is shared, with third-party model APIs replaced by self-hosted equivalents. If you want the bank-statement engine specifically, deployed and licensed for your own use, see the licensing page. ### What hardware do we need? It depends on model choice, quantization, and throughput, so the honest answer only comes after the evaluation. Departmental volumes commonly land on one to four modern datacentre GPUs; high-throughput pipelines need multi-node. The sizing report gives you a specific parts list with cost before you commit. ### Can we start hosted and move on-premise later? Yes, and it is often the sensible sequence — prove the workflow on the hosted API, then migrate once the requirement is real. Building the application against a provider-agnostic interface from the start makes that migration a configuration change rather than a rewrite. ### Who operates it after handover? Your team, with a runbook and training — that is the default and the goal. A support retainer is available for teams that would rather not own inference operations, covering upgrades, capacity planning, and incident response. ### Will you sign our security and compliance paperwork? Yes — NDA, DPA, and security addenda as required. Where I need access to your environment during deployment, that access is scoped, time-limited, and logged according to your own policy. ## Tell me what your compliance rules actually require The constraint usually determines the architecture. Send me the requirement — regulatory, contractual, or internal — and I will tell you what deployment shape satisfies it and roughly what it costs. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services/self-hosted-vision-language-models - https://parsemystatement.com/enterprise - https://parsemystatement.com/licensing - https://parsemystatement.com/services/custom-ocr-development --- # White-label bank statement parsing for your product > Put a production bank statement parser inside your own product under your own brand. White-label API, your domain, your pricing, volume-based licensing — no extraction team required. Source: https://parsemystatement.com/white-label Updated: 2026-09-17 If your product needs bank statement parsing but building an extraction team is not the business you are in, you can run mine under your own brand. A production engine with real, published accuracy benchmarks, exposed through your domain, priced for volume, with the option to move fully inside your infrastructure later. **At a glance** - Your brand, your domain, your pricing — the engine is invisible to your users - Live in weeks, not the two quarters an in-house build takes - Accuracy backed by a published ground-truth benchmark, not a datasheet claim - Upgrade path to a full source licence or on-premise deployment ## Who this is for Accounting and bookkeeping platforms whose users arrive with a folder of PDF statements. Lending and underwriting products that need transaction history from documents rather than an open-banking connection. Personal finance apps in markets where aggregation coverage is poor. Expense and audit tools that receive statements as attachments. Agencies delivering finance automation to clients. What these have in common: statement parsing is necessary but it is not your differentiator. Users judge you on underwriting quality, or reconciliation UX, or advisory value — not on how well you handle a two-column HSBC PDF. Meanwhile building it properly takes a specialist team six months and never stops needing maintenance, because every bank redesigns its statement layout eventually. White-labelling turns that from a hiring problem into a line item. ## What you get ### Your brand end to end API served from your domain, your naming in every response, your documentation. Nothing in the integration surface identifies the underlying engine to your users. ### Production API Async upload, status polling, and result fetch. Normalized transactions as JSON, CSV, or XLSX, with typed dates, signed amounts, references, merchant classification, and per-transaction page attribution. ### Built-in validation Every conversion is balance-checked — opening plus credits minus debits equals closing — and flagged when it fails, so your product can surface uncertainty instead of silently passing bad data to a lender or a ledger. ### MCP server included The same pipeline exposed as an MCP server, so AI agents built on your platform can call it directly. Increasingly this is what enterprise buyers ask about first. ### Volume pricing Per-page tiers that fall as you grow, with a committed-volume option. You set your own end-user pricing and keep the margin. ### Direct engineering access You talk to the person who wrote the parser. New bank layouts, schema additions, and integration problems are handled by the engineer, not a support tier. ## How onboarding works ### 1. Accuracy trial Send a representative sample of the statements your users actually upload. I run them through the engine and give you scored results, including the failures, so you evaluate on evidence rather than on a demo I curated. ### 2. Commercial terms Volume tiers, branding scope, support response times, and data-handling terms agreed. NDA and DPA signed. ### 3. Integration Keys issued, endpoints pointed at your domain, and integration support while your team builds against the API. Typically one to three weeks of your engineering time. ### 4. Layout coverage Banks that your users submit and the engine handles poorly get added as profiles. This is continuous work included in the relationship, not a change request. ### 5. Scale or bring it in-house As volume grows you either stay on the API, move to a deployment inside your own infrastructure, or take a full source licence. All three paths are open and priced. ## Ways to run it | Model | What it means | Best when | | --- | --- | --- | | Hosted white-label API | I operate it; your brand and domain in front | Fastest launch, no infrastructure to own | | Dedicated instance | Isolated deployment, your region, your retention policy | Data-residency requirements or high volume | | Deployed in your cloud | Runs inside your VPC under licence | Documents may not reach a third-party processor | | Full source licence | You own and modify the code | Extraction becomes core to your product | ## Indicative commercial terms Final pricing depends on volume, branding scope, and support level. These are starting points for the conversation, not a rate card. ### Launch — from $750 / month (Live in 2–4 weeks) For products validating statement parsing with early volume. - Hosted white-label API on your domain - Per-page volume tiers - CSV, XLSX, and JSON outputs - Email support with a business-day response - Accuracy trial on your statements before you commit ### Scale — Custom (Live in 3–6 weeks) For products where statement parsing is on the critical path. - Everything in Launch - Dedicated instance and region of your choice - Committed volume pricing - Prioritised bank-layout coverage - Named engineering contact and an agreed SLA ### In your infrastructure — Custom (6–10 weeks) The engine deployed inside your own cloud or datacentre under licence. - Runs entirely within your perimeter - Annual licence plus deployment engagement - Compliance and data-flow documentation - Upgrade path to a full source licence ## Frequently asked questions ### Will our users know the parsing is not ours? No. The API is served from your domain under your naming, responses carry no third-party branding, and the documentation is yours. Attribution requirements, if any, are agreed in the contract rather than baked into the product. ### Which banks are supported? The engine is layout-general rather than a fixed list of integrations — it reads statement structure rather than matching per-bank templates, so unfamiliar banks usually work on first contact. Bank-specific profiles then improve accuracy where a layout is unusual. The accuracy trial on your own statements tells you exactly where you stand before you sign anything. ### What happens to documents you process? On the hosted service, documents and outputs are deleted automatically within 24 hours, and retention can be shortened for your account. A DPA is signed as standard. If your requirements do not allow third-party processing at all, the in-your-infrastructure model exists for exactly that. ### What if we outgrow the API? Then you move — to a dedicated instance, a deployment in your own cloud, or a full source licence. The migration path is deliberate, because a white-label arrangement that traps you is a bad deal you would eventually leave anyway. ### Can we get an exclusivity arrangement? Category or geographic exclusivity can be discussed for committed-volume agreements. It is priced accordingly, since it forecloses other business. ### How is this different from building it ourselves? Time and ongoing cost, mostly. A capable team can build a first version in a few months; what surprises people is that extraction accuracy is permanent maintenance, not a project — layouts change, models change, and the evaluation harness needs feeding forever. If extraction is genuinely core to your product, build it, and hire me to help you do it properly. If it is not, license it. ## Test it on your own statements first Send a representative sample — including the ones that break other parsers. You get scored results with the failures included, before any commercial conversation. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/licensing - https://parsemystatement.com/enterprise - https://parsemystatement.com/services/document-data-extraction - https://parsemystatement.com/services/custom-ocr-development --- # License the extraction engine, the source, or the whole product > Source-code licensing, perpetual IP licensing, and acquisition options for a production bank statement extraction engine with a published ground-truth accuracy benchmark. Source: https://parsemystatement.com/licensing Updated: 2026-09-17 For companies where document extraction is core rather than incidental: license the source, take a perpetual IP licence, or acquire the product outright. What transfers is not just working code — it is the pipeline architecture, the bank profiles, the evaluation harness, and the ground-truth methodology that makes accuracy improvable rather than accidental. **At a glance** - Full source: Python extraction worker, Next.js application, and evaluation harness - The benchmark methodology transfers, so your team can keep improving accuracy - Perpetual, territory, and exclusive options available - Transition engineering support included in every structure ## What is actually being licensed The code is the smallest part of the value, and buyers who only evaluate the code tend to regret it. Anyone can write a script that calls an OCR API in an afternoon. What takes many release cycles of measured iteration to arrive at is everything around that call. The routing logic that keeps 60–80% of pages off the expensive path. The column-header hints that stop a Debit/Credit/Balance grid from collapsing into prose. The sign-reconciliation pass that infers direction from running balances instead of trusting a label. The balance check that catches errors no confidence score reports. The constrained-JSON normalization with tolerant parsing, so one malformed model response does not fail a 300-page document. The vision-escalation gate that improves the worst pages without multiplying cost across all of them. And underneath all of it: a ground-truth evaluation harness scoring every field against hand-written expected values from real statements, which is the only reason any of those decisions can be shown to help rather than merely believed to. ## Licensing structures ### Source licence, non-exclusive Full source code, perpetual right to use and modify inside your organisation, no obligation to contribute changes back. I continue to operate and license the product to others. ### Source licence, exclusive by segment Exclusivity within a defined vertical, geography, or customer segment. Priced against the business it forecloses, and requires a committed term. ### Perpetual IP licence Broad rights to the technology including the right to sublicense, while I retain ownership. The common structure for companies embedding extraction across a product portfolio. ### Full acquisition Product, code, domain, brand, customers, and benchmark methodology transfer. Structured with a transition period so the knowledge moves, not just the repository. ### Acqui-hire style engagement IP transfer combined with a defined period of my engineering time to embed the system into your stack and train your team to own it. ### Technology partnership Joint development where you fund extensions to the engine for your domain and receive a licence to the result. Suits teams with a specific document class and no extraction specialists. ## What transfers in a source licence | Component | Description | | --- | --- | | Python extraction worker | Routing, OCR integration, vision escalation, normalization, sign reconciliation, balance validation | | Next.js application | Upload, preview, exports, auth, billing, API keys, developer console | | Developer API | Async upload, status polling, result fetch, key management, quotas, usage logging | | MCP server | Agent-callable interface over the same pipeline | | Evaluation harness | Ground-truth scoring, per-statement postmortems, A/B comparison, CI accuracy gate | | Bank profiles | Layout knowledge accumulated across production conversions | | Deployment assets | Containerisation, worker orchestration, environment configuration, runbook | | Documentation | Architecture, failure modes, extension guide, and the accuracy methodology | ## Included in every licensing structure - Transition engineering support so the system is understood, not just delivered - A working deployment in your environment before the engagement closes - The evaluation harness and the ground-truth methodology behind it - Architecture and failure-mode documentation - An agreed period of question-answering access after handover - Warranties and IP representations appropriate to the structure ## How the process runs First a call to establish what you actually need — some companies arrive asking to buy the product when a white-label arrangement would serve them better and cost an order of magnitude less. I will say so. Then, under NDA, technical diligence: architecture walkthrough, code review, benchmark results, and a live run on your own documents so accuracy claims are verified rather than accepted. You should insist on that last step with any vendor. Then structure and price, which depend on exclusivity, term, and how much transition engineering is included. Then documentation, transfer, deployment, and handover, with a support period afterwards. Pricing is not published because these structures differ too much for a rate card to mean anything. Source licences and acquisitions are substantial commitments; if you are looking for a way to add statement parsing to a product for a monthly fee, the white-label option is the right page. ## Frequently asked questions ### Why would you license or sell technology you are actively operating? Because a company with distribution in a vertical can build more value on this engine than I can reach alone, and because a well-structured licence funds deeper engineering. The two are not in conflict — non-exclusive licensing in particular leaves the product running while the technology reaches more places. ### Is the accuracy claim verifiable before we commit? Yes, and verifying it is part of diligence. You supply statements with known correct values, we score the engine against them together, and you see the failures as well as the successes. The evaluation harness is exactly the tool for this, which is why it transfers with the licence. ### What are the ongoing dependencies? The hosted configuration depends on external model APIs for OCR and normalization. A licensee can run the same architecture entirely on self-hosted open-weight models — that configuration and its accuracy characteristics are documented, and standing it up is available as part of the transition engagement. ### Can we license only part of it? Yes. The extraction worker is the most commonly licensed component on its own, without the web application or billing. The evaluation harness can also be licensed separately, and for some teams it is the highest-value piece. ### What does diligence require from us? A signed NDA, a technical reviewer who can assess extraction systems, and a set of documents with known correct values for the accuracy verification. Diligence typically runs two to four weeks. ### Do you consider revenue-share instead of a fee? For the right partner, yes — particularly where you bring distribution and I bring the engine. It has to be structured with real reporting obligations to be worth anything to either side. ## Start with what you are trying to own Tell me whether you need the capability, the code, or the company. The answer changes the structure completely, and getting that right early saves both of us a month. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/white-label - https://parsemystatement.com/enterprise - https://parsemystatement.com/services/custom-ocr-development - https://parsemystatement.com/services/document-ai-consulting --- # Enterprise bank statement processing at volume > High-volume statement and document processing for finance, lending, and accounting teams — dedicated infrastructure, data-residency options, SLAs, custom schemas, and direct engineering access. Source: https://parsemystatement.com/enterprise Updated: 2026-09-17 For teams processing thousands of statements a month, the constraints stop being about accuracy alone and start being about throughput, residency, auditability, and what happens at 2am when a batch fails. Enterprise engagements cover dedicated infrastructure, custom output schemas, an agreed SLA, and a direct line to the engineer who built the pipeline. **At a glance** - Dedicated processing capacity, isolated from shared load - Data residency in your region, or deployment inside your own infrastructure - Custom output schemas mapped to your accounting or underwriting system - Direct engineering contact, not a support queue ## What changes at volume At ten statements a month, accuracy is the only thing that matters. At ten thousand, four other things start to dominate. Throughput: a batch that must clear overnight needs capacity planning and a queue that degrades predictably, not a best-effort shared service. Residency: your compliance team will ask where documents are stored and processed, and 'the cloud' will not be an acceptable answer. Auditability: you need per-document processing logs you can produce when someone asks how a number reached a ledger. And integration: raw transaction rows are not what your system ingests — it wants your schema, your account codes, your categories. Enterprise engagements exist to handle those four, on top of the extraction accuracy that is table stakes. ## What an enterprise engagement includes ### Dedicated capacity Isolated worker capacity sized to your peak batch, so your overnight run is not competing with shared traffic. Throughput agreed in documents per hour rather than left to chance. ### Custom output schema Transactions mapped to your chart of accounts, category taxonomy, or underwriting model — delivered in the shape your system ingests, not a generic CSV your team has to transform. ### Bulk and scheduled ingestion SFTP drops, S3 buckets, mailbox polling, or direct API. Batch tracking with per-document status, automatic retries, and a failure report you can act on. ### Residency and retention control Processing in your required region, retention windows set to your policy, and full in-your-infrastructure deployment where third-party processing is not permitted. ### Audit trail Per-document processing logs — which method read each page, confidence, validation outcomes, and timings — retained to your schedule and exportable for audit. ### SLA and engineering access Agreed uptime and response targets, a named engineering contact, and a quarterly accuracy review against your own document mix. ## Common enterprise use cases | Team | Workload | What matters most | | --- | --- | --- | | Lending and underwriting | Applicant statement packs at decision time | Latency, balance validation, audit trail | | Accounting and bookkeeping firms | Monthly client statement batches | Throughput, per-client schemas, ledger mapping | | Audit and forensics | Large historical archives | Bulk reprocessing, provenance, page attribution | | Expense and finance operations | Continuous receipt and statement flow | Integration, categorisation, exception handling | | Banks and financial institutions | Internal document processing | On-premise deployment, residency, supervision requirements | | Government and public sector | Regulated document workflows | Air-gapped deployment, procurement compliance | ## How enterprise onboarding runs ### 1. Requirements and volume review Volume, peak shape, latency requirement, residency constraints, and the output schema your systems need. This determines whether the answer is dedicated hosted capacity or deployment inside your infrastructure. ### 2. Accuracy trial on your documents A representative sample scored against ground truth you supply, so you evaluate on your own document mix rather than a generic benchmark. You see the failures too. ### 3. Commercial and compliance Pricing, SLA, DPA, security review, and procurement paperwork. I complete security questionnaires directly rather than routing them through a sales layer. ### 4. Integration build Ingestion path, custom schema mapping, and delivery into your systems, with engineering support throughout. ### 5. Production and review Ramped rollout, load validation at peak, then a quarterly accuracy and capacity review as your volume and document mix change. ## Enterprise requirements handled as standard - Signed DPA and data-processing terms - Security questionnaire and vendor-assessment support - Configurable retention, including immediate deletion after delivery - Regional processing and storage - Per-document audit logging with export - Balance validation and flagged-exception reporting - Named engineering contact with agreed response times ## Frequently asked questions ### What volume counts as enterprise? Roughly, when the published plans stop fitting — commonly a few thousand pages a month upward, or any volume at all where residency, SLA, or custom schema requirements apply. A small-volume workload with hard compliance constraints is an enterprise engagement too. ### How is enterprise priced? Committed annual volume with per-page tiers, plus a platform fee reflecting dedicated capacity, SLA, and support. Deployment inside your own infrastructure is licensed annually with a separate deployment engagement. Pricing follows the requirements review because the variables are too wide to publish. ### Can you meet our security review? I complete security questionnaires and vendor assessments directly. The current posture — encryption, retention, processing stages, subprocessors, and what is and is not certified — is documented publicly on the security page, deliberately without claiming certifications that do not exist. ### Do you support our accounting system? Output is mapped to whatever shape your system ingests — QuickBooks, Xero, NetSuite, Sage, or an internal ledger format. Schema mapping is part of integration rather than a separate product, and the mapping is tested against your real data before go-live. ### What if a batch fails at 2am? Failed documents are isolated with a reason rather than failing the batch, retried automatically where the failure is transient, and reported so your team can act. Response times for genuine incidents are set in the SLA, and you have a direct engineering contact rather than a ticket queue. ## Start with an accuracy trial on your own documents Send a representative sample and your volume profile. You get scored results including failures, a throughput plan, and a written price — before any commitment. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/white-label - https://parsemystatement.com/services/on-premise-deployment - https://parsemystatement.com/licensing - https://parsemystatement.com/services/document-data-extraction --- # 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 --- # Talk to the engineer who built it > Contact Parse My Statement for custom OCR development, document extraction projects, self-hosted model deployment, RAG work, white-label licensing, or enterprise processing. Source: https://parsemystatement.com/contact Updated: 2026-09-17 Every enquiry reaches me directly — there is no sales team in between. The most useful first message includes a sample document or a clear description of what you need extracted, because that is what lets me give you a real answer instead of a discovery call. **At a glance** - Replies from the engineer, usually within one business day - NDA signed before you share anything sensitive - Accuracy trials on your own documents, before any commitment - A straight answer when the thing you need is not something I should build ## What people contact me about ### Custom extraction projects OCR pipelines, document parsing, and structured extraction for document types that off-the-shelf tools handle badly. ### Self-hosted model deployment Vision and language models running on your own GPUs because your documents cannot leave your network. ### RAG systems Retrieval over document corpora, or a diagnosis of why the RAG system you already have is underperforming. ### White label and OEM Running the statement parsing engine inside your product under your own brand. ### Enterprise processing High volume, data residency, custom schemas, SLAs, and on-premise deployment. ### Licensing and acquisition Source licensing, perpetual IP licences, or acquiring the product outright. ## What to include for the fastest useful reply - What the documents are and roughly how many you process - Which fields you need out of them - Whether the documents are digital PDFs, scans, or photographs - Any constraint on where documents may be processed or stored - Your timeline and, if you have one, a budget range - A sample document — redacted or synthetic is fine to start ## On sending documents Do not send unredacted customer data in a first email. Redacted or synthetic samples are enough to assess feasibility, and once an NDA is in place we can arrange a secure channel for real documents. For accuracy trials I need documents together with known-correct values for a subset of them — the bank's own CSV export is usually the easiest source. That is what makes a trial a measurement rather than a demonstration. ## Frequently asked questions ### How quickly will you reply? Usually within one business day. Enquiries that include a document sample and a clear description get a substantive technical reply rather than a request for a call. ### Will you sign an NDA before we discuss details? Yes, as a matter of course. Send yours, or I can provide a standard mutual NDA. ### Do you do free proofs of concept? I will run a small document sample through the engine and give you scored results at no cost, because that is how you evaluate whether this is worth pursuing. Building a custom pipeline is paid work from the start. ### What if we only need the product, not a project? Then use it — the hosted product is self-serve and no conversation is required. Contact me when you need volume, custom schemas, data residency, or something that does not exist yet. ## Send the details The form reaches my inbox directly. Include the document type, the fields you need, and your timeline. Contact: adarsh@parsemystatement.com · https://parsemystatement.com/contact ## Related - https://parsemystatement.com/services - https://parsemystatement.com/about - https://parsemystatement.com/white-label - https://parsemystatement.com/enterprise ---