If your workflow is standard and your data holds no edge, buy a point tool. If it touches a regulated decision or runs on data only you have, the model is the easy part; build the pipeline around it. Most finance teams sit in between, where the answer is a build on bought components, trading control over lineage and evaluation against speed to first output.
That is the short version. The rest of this is how we get to it with a specific team, and the numbers we make them look at before anyone signs.
Three options, and what each one really costs you
There are three shapes on the table, and the marketing around all of them blurs the differences.
A point tool does one job. Expense categorisation, invoice extraction, a chatbot over your policy documents. You send data in, you get structured output back. The appeal is that it works next week. The cost you sign up for is that the vendor’s model was trained on everyone’s data, so it will never be better at your ledger than at your competitor’s, and you inherit their false-positive rate whether it fits your risk appetite or not.
A platform gives you components: a retrieval layer, an agent framework, connectors, maybe a hosted feature store. You still write the logic. The pitch is that plumbing is solved so you only build the part that is yours. Sometimes true. The failure mode is that the platform’s abstractions do not match how your data is actually shaped, and you spend the saved time fighting the connector instead of writing the connector.
An engineering-led build means you own the pipeline. You decide how features are computed, how lineage is recorded, what the eval set contains, and when a model version is allowed to ship. This is the slowest to first output and the only option that lets you defend a decision to a regulator with your own audit trail.
The mistake is treating these as a single spectrum from cheap to expensive. They are different bets about where your advantage lives. If your advantage is proprietary data and a decision that has to survive scrutiny, a point tool cannot do the job at any price. It solves a different problem, and no discount changes that.
The TCO model we actually use
Vendor pricing is a subscription line. Real cost is not. We put every option in the same table over three years and force the hidden columns to be filled in.
- Licence or infrastructure. Per-seat, per-call, or the GPU and hosting bill. The only line vendors volunteer.
- Integration engineering. Getting your data in and the output back into the system of record. This is where “two weeks to deploy” becomes a quarter.
- The evaluation set. You need a labelled set that reflects your own cases, with hard examples and edge cases, whether you buy or build. Nobody hands you this. Budget the analyst time to construct it and the process to keep it current.
- Monitoring and drift. Distributions move. A transaction-monitoring model calibrated on last year’s typologies decays. Someone has to watch the input distribution, watch the output rate, and retrain on a schedule.
- Incident response. When the model is wrong in production, who reconciles the damage, who explains it, and how long does the workflow run in manual fallback.
- Switching cost. The number that decides more than people admit. If your features, prompts, and evals are locked inside a vendor’s format, the price of leaving is the price of rebuilding. A low subscription with a high exit is expensive.
A worked example we run with clients: a point tool at a modest monthly fee looks like a fraction of a build over year one. Extend to three years, add the eval set you have to build regardless, add the integration work, and add a switching cost that assumes you outgrow the tool in year two, and the gap closes hard. The build is still more up front. It stops being obviously more once the full table is filled.
Two costs dominate and both sit on the build side of the ledger. The data layer is first. Point-in-time correct features, lineage you can query, and entity resolution across systems that spell the same counterparty three ways take longer than the model. Teams that skip this ship lookahead into their training set and get a beautiful backtest that collapses in production. The second is evaluation. You are not done when the demo works. You are done when you have a false-positive budget the business agreed to and an eval set that proves you are inside it.
How to decide
Run the workflow through four questions before you look at any pricing.
- Does your data give you an edge here? If the signal lives in your history and your relationships, buying a model trained on the market average throws away the reason to do this at all. Build or heavily customise. If the task is generic extraction, the market average is fine. Buy.
- What does a wrong answer cost? Miscoded expense, low. Wrongly declined applicant under ECOA, or a missed sanctions hit, high. The higher the cost, the more you need your own audit trail, your own thresholds, and control over when a version ships. That pushes toward build.
- Is the process stable or moving? A settled workflow is a good buy candidate. One you are still redesigning quarter to quarter will outrun a vendor roadmap, and you will spend the subscription fighting the tool’s assumptions.
- Can you staff the run, not just the launch? A build you cannot monitor is worse than a tool you can. If you have no one to own drift, retraining, and incident response, buy the thing someone else keeps alive, and be honest that you have accepted their false-positive rate as yours.
Most finance-ops teams end up with a hybrid. Buy the boring plumbing, foundation model access, an extraction service, a vector store. Build the part that touches the regulated decision and the part that runs on data only you hold. Draw the line at the point where you need to defend an output. Everything on the decision side, you own. Everything before it, buy if someone sells it cheaper than you can run it. None of this is ideology. Work out which side of that line each piece of the workflow sits on, and pay for control only where control earns its cost.
FAQ
When does a point tool actually make sense for a finance team?
When the workflow is standard, the vendor already holds no material advantage from your proprietary data, and the cost of a wrong output is low. Expense coding and contract extraction fit. Credit decisioning and transaction monitoring usually do not.
How do we compare vendor pricing to an in-house build fairly?
Put both on a three-year total-cost basis and add the columns vendors leave out: integration engineering, the eval set you have to build anyway, monitoring, incident response, and the cost of switching later. A cheap subscription with a punishing exit is not cheap.
What is the single biggest hidden cost in a build?
The data layer. Point-in-time correct features, lineage, and entity resolution take longer than the model work and are usually undercounted in the first estimate.