For a new invoice-processing feature, should we use a commercial model API, fine-tune an open model, or build our own? How do you decide?

TL;DR: Default to a commercial API: fastest to ship, no infrastructure, strong quality. Move to a fine-tuned open model when evals show it matches quality on your task and volume makes the savings worth owning it, or when residency or control requirements demand it. Build your own model only when the capability is a core differentiator, you have proprietary data with measurable lift, and you can sustain the investment. Re-evaluate as volume and models change.

How to approach it

Ask five questions: is this capability a differentiator or table stakes; is there proprietary data that measurably improves results; what volume makes which option cheaper; are there residency, latency or control constraints; and does the team have capacity to run models? Then apply them to invoice processing.

A strong answer

The framework.

Applied to invoice processing. Extracting fields from invoices (vendor, amounts, tax, line items) is valuable but not unique; many products do it. The company has years of processed invoices with corrected fields, which is good fine-tuning data. Volume will grow to millions of invoices a month.

1. Start with an API. Ship quickly with a strong multimodal or document model, measure accuracy on a golden set of real invoices across vendors, languages and formats, and learn the failure modes.
2. Evaluate a fine-tuned open model once volume is meaningful. Fine-tune on historical corrected invoices, evaluate on the held-out golden set. If it matches the API's accuracy on high-value fields, compute cost per correctly processed invoice for both, including the cost of running the model and the team's time.
3. Decide on evidence. If the fine-tuned model matches quality at substantially lower cost per invoice and the team can operate it, switch high-volume traffic to it and keep the API for hard cases. If not, stay on the API and revisit when volume or models change.
4. Own model: no. Invoice extraction is not differentiated enough to justify building a model from scratch.

Real cases point both ways, which is why the decision runs on your own evals. Uber's invoice-processing team tried a fine-tuned open model and found it reached over 90% accuracy on header fields but "didn't do well predicting the line's information", so line items went to a commercial model; the combined system reported about 90% overall accuracy and a 25-30% cost saving against the manual process (Uber engineering, April 2025, company-reported). On the other side, LoRA Land found narrow 4-bit LoRA fine-tunes beat GPT-4 by 10 points on average across its task suite (2024). Narrow, well-labelled fields favour fine-tuning; messy, variable structure favours the strongest model.

Price the managed option too, because it sets the ceiling. AWS Textract's expense analysis lists $0.01 per page for the first million pages and $0.008 after (US West, checked November 2026). If a correct invoice costs more than that on your own stack once review time is counted, buying wins.

Constraints that change the answer. If customers require in-country processing that the API provider does not offer, a self-hosted model becomes necessary earlier. If latency must be very low at the edge, a small model may be required.

What interviewers probe next

"Fine-tuning looks cheaper on paper. Why hesitate?" Owning a model means serving, scaling, monitoring, retraining when formats change, and re-evaluating when base models improve. Include those costs.

"The API provider cuts prices by half next year." Re-run the comparison. The gateway and portable eval set make switching in either direction cheap.

How it's scored

Common mistakes

Building a model for a capability that is not a differentiator.

Comparing token prices instead of cost per correctly processed document.

Forgetting the operating costs of owning a fine-tuned model.

See build, buy or fine-tune and fine-tuning and LoRA.