A dev.to tutorial keeps the AI model behind a small adapter in invoice summaries

Two jobs, kept apart

As dev.to reported in this tutorial, the core advice is to split invoice handling into two stages. First, a document specialist reads the invoice and pulls out the fields. Only then does an AI model write a short summary of what was found.

The reasoning is about diagnosis. Reading a scan (often called OCR, software that turns images of text into actual text) can go wrong in its own ways: a misread character, a confused table column, a repeated total. Summarizing can also go wrong even when every extracted value is correct. If both happen inside one model call, a poor summary looks just like a poor scan, and nobody knows where to look.

The author names Google Document AI, AWS Textract and Azure AI Document Intelligence as better fits for the reading stage than a chat model. The model is treated as a reader of tidy data, not as the system that holds the official record.

The handoff object

The piece centers on a small, deliberately dull data structure passed between the two stages. It holds the supplier name, invoice number, currency, total, due date, a count of line items, a list of fields the extractor was unsure about, and a note on which document and which extractor produced it.

That last part, provenance, matters. If a person reviews a questionable invoice later, they can see where each value came from. It also means you can replace the extraction tool without rewriting the summary instructions.

One detail is easy to miss. A due date that is absent from the invoice is not the same as a due date the extractor could not read. The tutorial says to keep both states visible, because a summary that blurs them could mislead someone in accounts.

Picking a model for the summary

The author compares Anthropic's Claude API, OpenAI's API and Google's Gemini API, plus a service called Infrai. This is explicitly not a quality ranking. Each is described as a reasonable choice, with the trade-off that you own the adapter, key rotation, retries and any backup provider.

The author's own recommendation leans toward Infrai when a team wants several providers behind one plain web interface, one that needs no software library installed. A team already committed to Claude is told that the direct Claude API is a defensible choice. Readers should note that this is one developer's preference, and the post ends by urging you to check the current request format yourself before building on it.

The larger point holds whichever vendor you choose. Your own code should expose the small contract it needs and keep provider-specific options out of the business logic. That is the "provider boundary" of the title, and it is why swapping in a Gemini model, as our hosts noted, would be easy.

Making the call safe to repeat

The example code is written in Python even though the title mentions Node.js, so Node developers will need to translate the idea rather than copy it. The summary instruction is short: write three concise sentences, say plainly which fields are missing or uncertain, and do not invent values.

The code also handles two practical problems. When the service answers that you are sending too many requests (an HTTP 429 response), the worker waits, either for the time the service suggests or for a growing delay, and tries again up to four attempts. It also sends the document ID as an idempotency key, a label that lets a service recognise a repeated request.

The author warns that this label is not enough on its own. Queues and network retries can deliver the same job twice, so the worker should store the normalized invoice and the accepted summary under one document ID and check for that record before writing again. Large batches deserve a token estimate first, since line items can swell a document, and incomplete or ambiguous invoices should go to manual review.

Where the pattern stops working

The tutorial names two limits. A chat model should not be the main tool for reading complex scans, and a single web interface does not erase differences between providers in behavior, limits and policy requirements.

The author also admits an early misjudgment: treating the summary as the interesting part. The expensive error is more often letting one extraction tool's field names or confidence scores harden into business rules. The suggested defense is testing with four sample invoices: one with a missing date, one with a duplicated total, one in a foreign currency and one with a malformed line item.

A fluent paragraph, the author notes, is not proof that the extraction underneath it was correct.