Build, buy, or have it built: three ways to automate finance ops

You have three options, and the right one depends on four things: time to first working workflow, three-year total cost, what happens when the requirement changes, and who fixes it when a source system changes a field. Building internally is the correct answer under specific conditions, and we name them below without softening them. Buying a SaaS platform fits standard processes with a named internal owner. Having it built fits workflows that matter, systems that change often, and teams with no spare capacity to maintain them. This post compares all three on the same axes, with an illustrative three-year cost model and every assumption stated.

Key takeaways

• Build vs buy finance automation is decided on four axes: time to first working workflow, three-year total cost, cost of change, and who owns maintenance.

• Building looks cheapest in year one because the cost is absorbed into an existing salary, not because it is small. Maintenance is the line nobody budgets.

• Buying works when your process matches the template. Configuration effort moves to your finance team, and so does maintenance.

• A workflow is not a purchase. It is a standing dependency on systems other people change without telling you.

• Genuine reasons to build exist: spare engineering capacity, proprietary logic central to your product, no usable API, or volume high enough that per-unit vendor pricing dominates.

• The three-year totals land closer together than most business cases assume. The real difference is who carries maintenance risk and key-person risk.

The three paths at a glance

Here is the short comparison. Cost shapes are illustrative and explained in full in the cost model section below.

| Path | Time to first workflow | Year-one cost shape | Three-year cost shape | Who fixes it when NetSuite changes | Key-person risk | Best fit | | --- | --- | --- | --- | --- | --- | --- | | Build internally | Four to twelve weeks, subject to sprint priority | Looks near zero, absorbed into existing salary | Highest, because maintenance compounds annually | Your engineer, if still employed and not on a deadline | High: logic lives with one person | Proprietary logic, spare capacity, no usable API | | Buy a SaaS platform | Days to weeks per workflow you configure yourself | Subscription plus internal configuration hours | Predictable subscription plus ongoing config hours | You do, inside the vendor tool | Medium: config knowledge sits with one admin | Standard processes with a named internal owner | | Have it built | Days, with the vendor doing the building | Service fee plus finance review hours | Flat and predictable, maintenance included | The vendor, as part of the service | Low: the vendor holds the build and the runbook | Workflows that matter, systems that change, no spare engineering |

Why this decision is harder than it looks

The decision is hard because the costs arrive on different schedules. Building front-loads effort and back-loads maintenance. Buying front-loads a subscription and back-loads configuration drift. Having it built flattens both into a single recurring fee. Most business cases compare year one against year one, which flatters the build option and hides where the money goes.

The stakes are measurable. APQC, drawing on more than 10,000 organizations, reports that top performers close the books in five days or less, the median is six days, and bottom performers take 10 or more calendar days. That spread is rarely about staff quality. It is about how much of the close depends on someone remembering to do something.

Path one: build it internally

Building means your own engineers write scripts, scheduled Python jobs, and integration code against your finance systems. You own the logic completely, and you can model anything your business does. The trade is that you also own every future change.

The initial build usually goes well. An engineer who understands your data can produce a working invoice-matching job in a couple of sprints. The problem appears in month seven, when NetSuite adds a required field, the job fails silently, and the person who wrote it has moved to a product team.

What building gives you:

• Complete control over logic, data handling, and error behaviour.

• No per-workflow vendor fee.

• Deep integration with internal systems no vendor supports.

What building costs you:

• Engineering hours that were promised to the product roadmap.

• A maintenance obligation that grows with every workflow you add.

• Documentation debt, because internal tools rarely get runbooks.

Path two: buy a SaaS platform

Buying means licensing a workflow platform with templates your team configures. Time to first workflow is short when your process resembles the template. The vendor maintains the platform and the connectors; you maintain the configuration.

This path is genuinely strong for standard processes. Vendor connectors to QuickBooks, Xero, Stripe, and Salesforce are maintained by people whose job it is to maintain them.

The limit is fit. Templates encode the average company's process. When your approval matrix has an exception for one entity, or your revenue recognition depends on a contract clause, you configure around the template until the configuration itself becomes the thing that needs maintaining. Ardent Partners finds that over 60% of invoices still require some human interaction, so the exception path is not an edge case. It is most of the work.

Buying also relocates labour rather than removing it. Somebody in finance becomes the platform admin. That role is real, unbudgeted, and concentrated in one person.

Path three: have it built and maintained

Having it built means a vendor designs, runs, and maintains the workflows on your existing systems, and your team approves only the exceptions. You get the speed of buying without becoming the configuration owner.

Loopfour, the deterministic finance workflow automation platform, takes this path. We build the workflows in Loopfour Studio, a visual canvas with 30 blocks across seven categories, on top of the stack you already run: QuickBooks, NetSuite, Xero, Sage Intacct, Rillet, Stripe, Salesforce, HubSpot, Attio, Slack, Gmail, Outlook, DocuSign, PandaDoc, Dropbox Sign, and Workday. Where no API exists, we fall back to browser automation.

Execution is programmatic and deterministic. The same inputs produce the same outputs on run number one and run number 1,000,000, and every action writes to an execution tree you can audit. Loopfour is not an AI agent with a wrapper around it. AI is called for scoped tasks only, such as classifying a vendor email or extracting a line item from a PDF, each with a confidence threshold. Below the threshold, the run routes to a named human approver as an exception. Your controller approves; the workflow does not guess.

Determinism matters more in finance than in most domains. The FinanceReasoning benchmark published at ACL 2025 (arXiv:2506.05828) tested 2,238 problems and found the strongest reasoning model reached 89.1% on the hard subset, with numerical calculation errors making up roughly 37.5% of failures. That is a strong result for a research benchmark and an unacceptable one for a close checklist. We use code for arithmetic and reserve models for judgment, under a threshold, with a human fallback.

When you should genuinely build

Building is the right answer more often than vendors admit. If any of the following describe you, build, and do not let a sales deck talk you out of it.

You have spare engineering capacity and a stable roadmap. If an engineer has genuinely uncommitted time and your product plan is not capacity-constrained, internal build is cheap and fast. The cost only bites when that time was already promised elsewhere.

The logic is proprietary and central to your product. If your billing rules are a differentiator, encoding them in a vendor tool exports your advantage into someone else's schema. Usage-based pricing engines, marketplace payout splits, and bespoke revenue recognition belong in your codebase.

Your systems have no usable API and you need deep custom integration anyway. If your ERP is on-premise with a database you already query, you have the hard part solved. Adding a vendor layer buys you a connector you do not need.

Your volume is high enough that per-unit vendor pricing dominates. At millions of transactions, per-record or per-run pricing overtakes engineering cost. Model it. If the crossover is inside 18 months, build.

The condition that invalidates all four is the same one: the work has to stay funded after the person who built it leaves.

The maintenance question is the real differentiator

Maintenance is where the three paths separate, because a workflow is a standing dependency on systems other people change. NetSuite adds a required field. Stripe deprecates an endpoint. Your controller changes the approval threshold from $5,000 to $10,000. None of those changes are announced to you in a way that reaches the person who owns the script.

The failure mode is not a loud crash. It is a silent one: the job runs, skips 40 records, and reports success. You find out at close.

| Failure mode | Build | Buy | Have it built | | --- | --- | --- | --- | | Source system adds a required field | Engineer debugs, priority depends on sprint | You reconfigure the mapping | Vendor detects and repairs | | Approval threshold changes | Code change, review, deploy | Config change in the tool | Requirement change request | | Original author leaves | Logic is undocumented, reverse-engineered | Admin knowledge gap | No change, vendor holds the build | | Silent partial failure | Detected at close, if at all | Depends on tool alerting | Execution tree flags the run |

Two data points frame what maintenance is protecting. IOFM puts the manual invoice error rate at roughly 2%, against below 0.8% once automated. Levvel Research puts the manual cost per invoice at $10 to $15, against $2 to $3 automated. Those gains are real, and they only persist while the automation keeps working. An automation that silently degrades gives back the error-rate improvement first and tells you last.

This is the axis on which we compete. Your team approves exceptions. We keep the workflows running when the source systems change.

An illustrative three-year cost model

The model below is an illustrative scenario, not a quote and not a benchmark. Every figure is an assumption we have stated so you can replace it with your own. Loopfour outcome figures anywhere in this post are illustrative and projected.

Assumptions:

• Scope: five workflows of moderate complexity, such as invoice matching, dunning, approval routing, close checklists, and revenue schedules.

• Engineer fully loaded cost: $180,000 per year across 2,000 hours, so $90 per hour.

• Finance operations manager fully loaded cost: $130,000 per year across 2,000 hours, so $65 per hour.

• Build effort: 80 engineer-hours per workflow to first production version.

• Configuration effort on a bought platform: 30 finance-operations hours per workflow.

• Maintenance for a built workflow: 100 engineer-hours per workflow per year, made up of 60 hours routine and 40 hours reworking breaks caused by source-system changes.

• Maintenance for a bought workflow: 20 finance-operations hours per workflow per year.

• Placeholder fees, not tied to any named vendor: $30,000 per year for a SaaS platform subscription, $40,000 per year for a managed service including build and maintenance.

• Maintenance is counted from year one in all three paths.

| Cost line | Build | Buy | Have it built | | --- | --- | --- | --- | | Year-one build or configuration | $36,000 (400 engineer-hours) | $9,750 (150 finance hours) | Included in fee | | Annual fee | None | $30,000 | $40,000 | | Annual internal maintenance or review | $45,000 (500 engineer-hours) | $6,500 (100 finance hours) | $3,900 (60 finance hours) | | Year-one total | $81,000 | $46,250 | $43,900 | | Three-year total | $171,000 | $119,250 | $131,700 | | Cash budgeted in year one | Often $0 | $30,000 | $40,000 |

Read the last two rows together. The build column has the highest three-year cost and the lowest budgeted cash, because the engineering time is already on payroll. That is why build wins the business case and loses the three-year comparison. Maintenance compounds, and nobody enters it into the spreadsheet.

One line sits outside the totals deliberately. The build path consumes 500 engineer-hours per year that are not spent on your product. Price that against your roadmap, not against a vendor fee. If those hours are genuinely idle, the build case strengthens. If they are not, the true cost is higher than the table shows.

A decision framework you can apply this week

Answer four questions in order. The first clear yes gives you your path.

| Question | If yes | Why | | --- | --- | --- | | Is the logic proprietary and central to what you sell? | Build | Exporting a differentiator into a vendor schema costs more than engineering hours | | Do you have uncommitted engineering capacity and a stable roadmap for three years? | Build | The maintenance tail is affordable when the capacity is genuinely free | | Does your process match a standard template, and do you have a named internal owner with time to configure it? | Buy | Configuration effort is real but bounded, and vendor connectors are maintained for you | | Do the workflows matter, do the source systems change often, and is nobody free to maintain them? | Have it built | Maintenance is the recurring cost, so buy the maintenance rather than the tool |

Two tests to run before you commit. First, ask who is on call when the workflow breaks during close, and get a name. If the answer is a role rather than a person, you do not have a maintenance plan. Second, ask what happens when the requirement changes in month eight, and price that change on each path.

The market is moving on this. Protiviti's 2025 SOX survey found nearly 70% of organizations have implemented automated compliance tools, and 68% are prioritising further technology and automation. The question in most finance teams is no longer whether to automate but who carries it.

Frequently asked questions

What is the difference between build vs buy finance automation and a managed service?

Build means your engineers write and maintain the code. Buy means you license a platform and configure it yourself. A managed service means a vendor builds, runs, and maintains the workflows on your existing systems while your team approves exceptions. The third option differs from buying because maintenance transfers to the vendor rather than to your finance team.

How do I calculate the total cost of ownership for finance automation?

Add four lines: initial build or configuration hours at a fully loaded rate, any annual fee, annual maintenance hours, and the rework caused when source systems change. Then track the opportunity cost of engineering time separately, because it is a roadmap decision rather than a finance one. Model three years, not one. Year-one comparisons favour building because the labour is already on payroll.

When does building finance automation in-house make sense?

Build when the logic is proprietary and central to your product, when you have genuinely uncommitted engineering capacity and a stable roadmap, when your systems have no usable API and you need deep custom integration anyway, when volume is high enough that per-unit vendor pricing dominates, or when the process will not change. Each of those conditions removes the maintenance problem rather than hiding it.

What happens to my workflows when NetSuite or Stripe changes a field?

On the build path, your engineer debugs it whenever sprint priority allows. On the bought path, you reconfigure the mapping yourself. On the managed path, the vendor detects and repairs it. Loopfour monitors and maintains the workflows we build, and your team is asked only to approve exceptions.

Is deterministic workflow automation different from an AI agent?

Yes. A deterministic workflow executes programmatically, so the same inputs produce the same outputs on every run, and each action is recorded in an audit trail. Loopfour calls AI for scoped tasks such as classifying an email or extracting a field, each governed by a confidence threshold. Below the threshold, the run routes to a named human approver.

How fast can finance workflows go live, and what does automation change?

Manual invoice cycle time averages 14.6 days, against three to five days once automated. Time to first working workflow depends on the path: weeks when building, days to weeks when configuring a bought platform, days when a vendor builds it for you.

What security and compliance controls should I require?

Ask for SOC 2 Type II certification, encryption in transit and at rest, and a written commitment that your data is not used to train models. Loopfour is SOC 2 Type II certified with a SOC 1 audit underway, supports HIPAA controls, uses AES-256 at rest and TLS 1.3 in transit, and does not train models on customer data.

Where to start

Pick the path that matches your conditions, not the one with the best year-one number. If the logic is proprietary or your engineering capacity is genuinely free, build, and budget the maintenance honestly. If your process is standard and someone owns configuration, buy. If the workflows matter and nobody has capacity to keep them running, have them built.

Loopfour is in Early Access with white-glove onboarding, free during beta, and no credit card required. Bring one workflow that breaks most often and we will map it with you.

Book a workflow review.