{"slug": "before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish", "title": "Before asking which AI to buy, ask what better looks like from start to finish", "summary": "Finance leaders should evaluate AI tools by measuring the cost of complete processes, not individual features, according to an article urging a shift from asking 'which AI to buy' to defining what better looks like end-to-end. The piece outlines a framework using unit costs—such as processing a business card transaction or resolving a personal purchase on a company card—that include business users' time, finance and approvers' time, and full software costs, to establish a baseline for improvement.", "body_md": "\"Which AI should we implement in the finance function?\"\n\nI get some version of this question every week. From founders, from CFOs, from recruiters writing job specs for AI-native finance leaders who have already implemented an AI-native ERP.\n\nIt is an understandable question. Finance leaders are being asked to improve productivity, strengthen controls and support a growing business without growing the team at the same rate. AI promises help with all three.\n\nIt is also a familiar question. We have been asked versions of it for years, with the technology swapped out. Machine learning. Then RPA. Then iPaaS. Now AI.\n\nEach time, it starts too far downstream.\n\nBefore choosing the technology, we need to understand where the work happens, what makes it expensive, and which responsibilities we want to take on ourselves.\n\nLook at where finance work actually happens. Travel is in a booking tool. Expenses and cards are in a spend platform. Billing might run through Stripe and something custom. FP&A has its own application. HR is one provider, payroll another, sometimes several more if the company operates across countries. Tax may be in-house or outsourced. Bill processing has an entire market of applications of its own.\n\nAnd between those systems sit the reconciliations, allocations and schedules that someone still maintains in Excel.\n\nIn many companies, the ERP serves as the accounting backbone, while much of the operational work happens in connected applications. By the time an entry reaches the ledger, several people and systems may already have touched it.\n\nSo when the conversation turns to an AI-native ERP, the useful question is: which part of this process does it improve?\n\nBank statement processing, bill capture and ledger chat can be useful capabilities. But those features alone do not establish how well a product handles the complete process.\n\nThe ERP is one part of the evaluation. We need to examine the whole landscape.\n\n## Measure the completed process\n\nTake a single card transaction.\n\nAn employee buys something. They find the receipt, submit it, choose a category and explain the business purpose. Depending on the policy, a manager approves it. Finance checks the treatment, resolves whatever is missing and makes sure the transaction reaches the ledger correctly. Somebody reconciles it later.\n\nA spend platform can automate several of those steps. It also requires work of its own: maintaining users, mapping categories to the chart of accounts, correcting receipt matches, investigating incomplete exports and explaining to employees where to submit things.\n\nBoth belong in the evaluation. The subscription price captures neither the full benefit nor the full operating cost.\n\nA feature can save time inside an application without saving time across the process. An approval becomes faster but produces more exceptions for finance. Receipt capture improves while employees spend longer fixing categories. An integration removes a manual export, but somebody still needs to establish whether every transaction arrived.\n\nThe unit of analysis is the completed process, not the screen.\n\nFor spend management, I start with four unit costs:\n\n1. Cost to process one business card transaction.\n2. Cost to process one out-of-pocket reimbursement.\n3. Cost to resolve one personal purchase made on a company card, including identification, recovery and correct accounting treatment.\n4. Cost to process one mileage request.\n\nEach includes three components:\n\n- Business users' time: submitting, explaining, correcting and chasing.\n- Finance and approvers' time: reviewing, handling exceptions, posting and reconciling.\n- Full software cost: licences, implementation, integration, administration and ongoing maintenance.\n\nThe categories need clear boundaries so that the same work is not counted twice. Shared costs need a consistent allocation, and routine transactions should be distinguishable from exceptions.\n\nThis gives us a baseline. It makes visible the costs that a subscription comparison misses.\n\nThen we need to ask whether the process works well.\n\nRun quality measures alongside cost: turnaround time, correction rate, the share of transactions completed without manual intervention, and whether exceptions reach someone able to resolve them. Check whether approvals were applied as intended and whether supporting evidence is available.\n\nRead those measures together. A low average processing cost can conceal a handful of expensive failures. A high automation rate can conceal errors discovered during the close. A process that becomes cheaper by weakening necessary controls may simply move effort and risk downstream.\n\nThe objective is dependable completion at an acceptable cost.\n\nThat gives AI a concrete test. If a feature improves those outcomes enough to justify its full cost, it is valuable. The same is true of a conventional rule, a better integration or removing an unnecessary approval.\n\nThe technology matters. It determines what is possible, how reliably it works and what it costs to keep working. The label \"AI-powered\" does not answer those questions.\n\n## Ask what the vendor contributes\n\nOnce the process is visible, ask what each product is doing for the company.\n\nA spend product may combine banking and card infrastructure with receipt capture, policy controls, approval routing, accounting integrations and support. Some of those capabilities may overlap with services the company already buys.\n\nWhere an existing platform meets the requirements, a separate product has to justify its additional cost, administration and integration work. Where the requirements exceed that platform's capabilities, a specialist product may earn its place.\n\nCalling something a workflow layer does not prove it is expendable.\n\nA mature workflow may contain years of accumulated handling for cases that look trivial until they fail. Depending on the service, the vendor may maintain integrations, support changing requirements, enforce permissions, preserve audit evidence and help users resolve payment problems.\n\nThose are real responsibilities. Bringing the workflow in-house means assigning them to somebody else.\n\nThe question is how well the vendor carries those responsibilities, and whether the price is reasonable compared with the alternatives.\n\n## Decide where control is worth the responsibility\n\nThere is still a strong case for controlling more of your own operating logic.\n\nThe signs are familiar. The same policy is configured differently in four tools. A routine approval change requires extensive workarounds. Accounting treatment depends on a spreadsheet two people understand.\n\nAt that point, the company is paying for software while maintaining a parallel process around its limitations.\n\nSome rules deserve deliberate ownership: approval thresholds, allocation methods, entity treatment, exception routing and the conditions under which a transaction can post automatically.\n\nOwnership means being able to read those rules, see how they were applied, test a change, establish who authorised it and move them if the surrounding technology changes.\n\nThat does not require custom software. A purchased platform may provide enough visibility, flexibility and portability. For a standard process, adopting the vendor's conventions can be the economical choice.\n\nGreater control earns its keep when the rules change frequently, span several systems or materially shape how the business operates.\n\nThe benefit is flexibility. The price is responsibility.\n\nSomebody must document the logic, manage access, test changes, monitor execution and fix failures. Somebody else must be able to take over when that person leaves.\n\nMoving rules out of several applications can reduce fragmentation. It can also create a new dependency on a central platform or a small internal team. That tradeoff belongs in the decision.\n\n## Compare complete costs\n\nBuild-versus-buy arguments often compare a full vendor bill with a partial internal budget.\n\nFive tools at €50,000 a year cost €1 million over four years, before internal administration and integration costs. That looks like a substantial budget for an internal alternative.\n\nBut how much remains after infrastructure, platform licences, development, testing, support and continuity? Can the internal team deliver the same scope and service level, including when something fails during a payment run?\n\nApply the same accounting to the purchased option. Include implementation, configuration, administration, integration maintenance and the effort spent working around product constraints.\n\nThe comparison needs the same scope, service level and time horizon, with realistic assumptions about transaction growth, changing requirements and failures.\n\nUntil both sides are complete, €1 million is a headline, not a business case.\n\nBe equally accurate about the savings.\n\nMinutes recovered across thousands of employees can reduce friction and create useful capacity. They do not automatically become cash savings. Time recovered within finance may support better analysis, reduce overtime or allow the business to grow without another hire.\n\nThese are different outcomes. State which one the business case expects, and how the company will realise it.\n\nThe strongest evidence is a measured pilot: one defined process, a baseline and a record of what changed. Include implementation effort and the work required to keep it running.\n\n## Give agents the same test\n\nAgents may change the economics of finance software.\n\nAn agent that can read a receipt, retrieve the relevant policy, propose accounting treatment and route an exception could reduce the need for people to move between applications. It could also make some workflow functionality easier to reproduce elsewhere.\n\nThat is worth testing.\n\nPermissions still need to be enforced. Duplicate postings need to be prevented, detected and corrected. Decisions need to be traceable. Failed actions need to be detected and recovered. Uncertain cases need to reach a person able to resolve them.\n\nPerforming the visible steps is only part of the job. The surrounding controls and operating responsibilities remain.\n\nSo the test stays the same: does the agent reduce total effort, preserve or improve controls, and run reliably at an acceptable cost?\n\nSometimes the answer may justify replacing a specialist product. Sometimes it may justify running the agent inside that product, where the controls and transaction handling already exist.\n\nThe conclusion should follow the evidence.\n\n## Hire for that judgment\n\nThis also answers the hiring question.\n\nExperience implementing AI is useful. So is experience shortening a close, fixing a reconciliation process or consolidating a fragmented stack. What matters is what improved and whether the improvement lasted.\n\nCan the person explain where work accumulated? Can they distinguish a process problem from a software limitation? Can they establish a baseline, assess controls and compare the full cost of alternative approaches?\n\nDo they know when a standard product is sufficient and when greater control justifies the maintenance burden?\n\nAsk them to walk through one process they changed: what it cost before, where it failed, what they introduced and what responsibility the team took on afterwards.\n\nThat will tell you far more than the label on the technology they implemented.\n\n\"Which AI should we buy?\" becomes a useful question once you know which work should disappear, what it costs today and how you will know the process has improved.\n\nBy then, you have a concrete job for the technology — and a way to tell whether it did it.", "url": "https://wpnews.pro/news/before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish", "canonical_source": "https://ar-ti-fi.com/blog/what-better-looks-like", "published_at": "2026-09-08 00:00:00+00:00", "updated_at": "2026-09-08 12:01:37.436345+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-products"], "entities": ["Stripe"], "alternates": {"html": "https://wpnews.pro/news/before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish", "markdown": "https://wpnews.pro/news/before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish.md", "text": "https://wpnews.pro/news/before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish.txt", "jsonld": "https://wpnews.pro/news/before-asking-which-ai-to-buy-ask-what-better-looks-like-from-start-to-finish.jsonld"}}