Short answer: reading invoices, purchase orders, claim forms and delivery notes is mostly a lookup job, and it doesn't need the most expensive AI model on every step. A small model, or a dedicated extraction model, can pull the fields; ordinary code can do the maths; and the big model can be kept for the one step that needs judgement or a reply. Cloudflare's own test this week found that split about three times faster and roughly half the cost, with the same right answers.
Most teams set these jobs up the other way round. Someone tries ChatGPT or Claude on an invoice, it works, and the whole process gets built on the biggest model available. That's fine at 50 documents a month. At 5,000 the bill and the waiting time start to matter.
What Cloudflare tested
On 19 October 2026 Cloudflare released Clairic in preview. It's an extraction model: you hand it a document and a list of fields you want (amount, date, policy number, and so on), and it returns one typed value per field in a single pass. It doesn't write sentences. Each answer comes with a confidence score, and if a value isn't in the document it returns null instead of guessing.
Cloudflare tried it on an insurance-claims example. One pipeline used a large language model for all three steps: pull the facts, decide on the claim, write the reply. The other used Clairic to extract, a small decision model to decide, and the large model only to write the reply.
The split pipeline took 19.3 seconds against 61.7, and cost $6,032 per million claims against $11,740. Both got the facts and the decision right in every run. One detail stands out: Clairic's repair estimate was the same every time, while the large model gave $250, $250 and then $220 for the same claim.
These are Cloudflare's own demo numbers on its own product, so treat them as a direction to test on your own documents. The direction is still worth acting on.
Why the big model is the wrong default
Two reasons, and neither is about quality.
Price. Model prices are spread very wide. On Anthropic's price list today, Claude Haiku 5.5 costs $0.10 per million input tokens for normal-length prompts, while Claude Opus 5.5 costs $4. That's 40 times more for the same page of invoice text. If the cheap model reads the vendor name and GSTIN correctly, the extra spend buys nothing. Both drop by half again if you send work in batches and don't need answers instantly.
Consistency. A chat model writes its answer fresh each time, which is why it's good at replies and slightly unpredictable with numbers. For a field like "invoice total" you want the same answer every time you ask, and a tool built for extraction is designed to give you that.
How to split the work
Take any document-heavy process, such as vendor bills in accounts payable, claim forms, KYC papers or delivery challans, and break it into steps.
- Read. Pull the fields you need into a fixed list. A small model or an extraction model does this.
- Calculate. Totals, GST splits, matching a bill against its purchase order. Use a spreadsheet formula or a few lines of code. Cloudflare says Clairic isn't yet reliable at multi-step arithmetic, and chat models make the same kind of slip.
- Decide. Simple rules ("amount matches PO within ₹100, vendor is approved") cover most cases. A model only needs to step in for the unclear ones.
- Check. Anything with a low confidence score goes to a person. Everything else flows through.
- Write. If the process ends in an email to a vendor or a customer, that is where a stronger model earns its price.
Most of the cost in a typical setup sits in steps 1 and 3, run on a model meant for step 5.
The Indian shortcut: e-invoices are already data
Before buying any AI for supplier bills, check how many of them are GST e-invoices. Businesses with aggregate turnover above ₹5 crore have had to issue e-invoices for B2B supplies since 1 August 2023. Each one is registered with an IRN and signed, and suppliers and buyers can both download the signed e-invoice data from the e-invoice portal for six months after it's issued.
That data is already structured. Reading the PDF of an e-invoice with AI means paying a model to recover information you could fetch directly. Save the AI for what's left: scanned bills from smaller vendors, emailed quotes, handwritten challans and forms that never touch the GST system.
Where this doesn't apply
Some documents need real reading, not field lookup. A contract clause, a complaint letter, a messy email thread with three people changing an order: here a stronger model is worth paying for, because the job is understanding.
And if you process a few dozen documents a month, none of this matters much. Use whatever works and spend the time elsewhere. The split pays off when volume is high or the process runs every day.
What to ask whoever builds it
If a vendor or your own team is building document automation, ask which model runs each step and why. Ask what happens to a low-confidence field. Ask where the maths is done. If the answer is "one big model does everything", you are probably paying for capacity you don't use. Our operations automation page lists the kinds of processes where this comes up most.
Arthat AI
Working on something similar at your company?
Arthat AI builds these automations for Indian businesses every week. If you want to talk through whether this fits your situation, we'll give you a straight answer — even if the answer is "don't build it."
