There is a growing belief that with today’s AI tools, organisations can simply build their own accounts payable automation.
This belief isn’t completely unjustified. AI has lowered the barrier to entry: adoption has ramped up across industries, development tools are easily accessible, and a culture of experimentation has been growing around them. Building internally now seems viable.
In some areas of AP, that perception is fair. But in most, the story is a lot more complicated. That’s because AP automation can look straightforward from the outside. The recipe goes: extract data from invoices; match them to purchase orders; route for approval; post to the ERP; then pay suppliers. Job done.
But in practice, each of those steps hides a lot of complexity. And that complexity is where the real build versus buy decision lives.
This is the first of two articles examining what the build decision actually involves when the domain is accounts payable. As an AI architect working in this space, I want to lay out what I see when I look at the full picture.
The rise of “just build it with AI”
The narrative around building in-house has shifted significantly over the past eighteen months, and it’s easy to see why. Cloud development environments, foundation model APIs, AI coding assistants and autonomous software agents have lowered the barrier to getting started with internal tooling. Prototyping is faster. Implementation is more accessible. Tasks that once required dedicated engineering teams can now be bootstrapped with a fraction of the effort. None of that is hype. It’s real progress.
Across the software industry, companies are now asking a reasonable question: what are we paying for that we could build ourselves? That question is a legitimate challenge to software vendors, and I’m not going to pretend otherwise. Early in this AI cycle, enterprises moved to work directly with foundation models and build internal applications. The momentum toward internal builds is real, and it’s easy to understand why.
But momentum and readiness are different things. The conversation around building tends to focus on what’s become easier: getting started, extracting data, wiring up an initial workflow. What it tends to skip are the layers that determine whether a system can actually operate in production: governance, compliance, auditability, security, and the unglamorous work of ongoing maintenance.
For accounts payable specifically, the gap between a promising prototype and a reliable, auditable, production-grade system is wider than most organisations expect. And in finance, the system you ship has to be compliant, auditable, secure, and accurate enough to process real payments against real deadlines, every day, without exception. That’s where the stakes sit.
What it actually takes to build an AI AP system
One of the things that makes the build conversation tricky is that parts of it really have become easier. Data extraction from invoices, for instance, used to be a genuinely hard problem. With modern large language models (LLMs), it’s improving rapidly. If the entire challenge of AP automation were pulling structured data from a PDF, the case for building internally would be strong.
But extraction is just the front door. What follows is where things get complicated, and it’s where I think AP teams often underestimate how difficult the next steps really are.
Take purchase order matching. On the surface, it sounds mechanical: compare the invoice to the PO and check that the numbers line up. In reality, it is one of the trickiest problems in the entire AP pipeline. At SoftCo, we’ve invested years developing classical machine learning approaches to handle matching accurately, because the variations, partial deliveries, pricing discrepancies and exception patterns that occur in real-world data make this a deeply specialised task. Generative AI alone wouldn’t achieve the same level of accuracy at this stage. This is a problem that requires accumulated domain knowledge, not just a capable model.
And matching is only one step in a longer chain. Once data has been extracted and matched, it still needs to be:
- Coded to the correct general ledger accounts
- Routed through the right approval workflows
- Checked for exceptions and discrepancies
- Reconciled against supplier records and contract terms
Each of these compounds in complexity as volume increases. Getting any one of them slightly wrong at scale doesn’t just create errors. It creates manual work, which is exactly what the automation was supposed to eliminate.
Then there’s the compliance layer, which is not an add-on. It’s foundational. Fraud detection, duplicate payment prevention, complete audit trails, certifications like SOC 2 and ISO 27001. In this domain, these are table stakes. They need to be engineered into the system from the start, not bolted on after the fact.
This is one of those areas of software where domain knowledge matters more than in most. There is a lot of very specific, accumulated understanding that needs to be brought to bear on the problem, and AP automation is not as forgiving as some other types of software you might choose to build.
The evidence supports that caution. Nearly half of AI proof-of-concept projects were scrapped before reaching production in 2025, with 42% of companies abandoning most of their AI initiatives entirely. The pattern isn’t that AI doesn’t work technically. It’s that organisations are often not structurally prepared to operationalise it, particularly in domains where precision, compliance and domain expertise are non-negotiable.
The hidden operational burden
Even if an organisation clears every hurdle above, there’s a second category of challenge that tends to be invisible at the planning stage. It’s not about whether you can build the system. It’s about what happens once you have to live with it.
Maintenance is not a one-time event
One of the most persistent misconceptions about building internal tooling is that the difficult part ends at deployment. In AI-powered systems, deployment is closer to the beginning.
With modern LLMs, invoice format variation is becoming less of an issue. But format variation was never the only thing that changes. What shifts constantly are the integrations: ERP connections evolve, APIs get updated or deprecated, and new regulatory requirements emerge. In Europe, for example, the rollout of Peppol and digital e-invoicing standards is creating an entirely new set of compliance demands that any AP system needs to accommodate.
The point is straightforward. You can’t build this once and leave it running quietly in the background for years. The software needs to keep being adapted and upgraded to meet new requirements as they come along. That’s not a risk. That’s the operating reality.
The broader research on AI systems reinforces this. The NIST AI Risk Management Framework explicitly treats AI as a lifecycle system requiring continuous governance and management, not a deployment event. Research into model drift shows that accuracy can degrade within days of deployment when production data diverges from what the model was trained on. And a study on temporal degradation in AI models found that even high-accuracy models do not remain static over time, and significant effort needs to be dedicated to monitoring and reducing that degradation.
Maintenance in AI is an ongoing function. Treating it as a completed task is how systems quietly fail.
The POC-to-production gap
Getting a proof of concept working is a meaningful accomplishment, but it’s only the start of the story. The distance between a working prototype and a production-grade system is one of the most consistently underestimated gaps in enterprise software.
It’s relatively straightforward to get individual parts of the AP process working in isolation. Extracting data from an invoice, generating an approval notification, pushing a record to an ERP. As standalone tasks, these are doable. But deploying a complete system, maintaining it, and keeping it secure on an ongoing basis is a fundamentally different challenge, especially when you’re integrating with third-party systems like ERPs.
Those integrations change over time. Connections need to be maintained. New vulnerabilities in the software stack come to light and need to be patched. Configuration requirements shift. These are not one-off tasks. They are permanent operational overhead.
What tends to be invisible at the POC stage is this entire layer of ongoing work. Building and maintaining and operating software in-house has its own hidden costs, and those costs can be significant. The gap between AI ambition and operational reality is well documented: 87% of CFOs view AI as extremely or very important, but only 21% report clear, measurable value delivered. That gap is largely explained by what happens after the initial build.
Monitoring and operational risk
Any production system that processes financial data needs dedicated monitoring and operations capability. There’s no way around this. You need observation in place, and you need someone watching the alerts to make sure everything is running as it should be.
This might sound like standard operational hygiene, and it is. But the consequences of getting it wrong in AP are more immediate and more visible than in many other domains.
If your own in-house automation goes down, the impact is felt quickly. Suppliers don’t get paid. Penalties start to accrue. Internal teams scramble to restore service, and the cost to the business isn’t theoretical. It lands in supplier relationships, in cash flow, and in confidence.
This is the equivalent of maintaining a customer success and operations team purely for internal tooling. Most organisations don’t scope for it when they plan a build. But once the system is live and processing real invoices against real deadlines, monitoring isn’t optional. It’s an operating requirement, and someone has to own it.
What comes next
This article has covered the technical and operational reality of building AI-powered AP automation internally. The tools are better. The starting point is easier. But the full scope of what “build” means, once you account for matching complexity, compliance requirements, integration maintenance, and ongoing operations, is substantially larger than most organisations anticipate.
In Part 2, we’ll look at what it actually costs to run and govern an AI AP system over time: the auditability and security standards, the total cost of ownership, the domain knowledge gap that separates demo-ready from audit-ready, and the criteria for deciding when building makes sense and when it doesn’t.
Frequently Asked Questions
Yes, a company can build its own accounts payable automation system with AI, especially for narrower tasks like invoice data extraction. But building a production-ready AP automation platform is much more complex than creating a proof of concept. Once you move beyond extraction, you need to handle PO matching, GL coding, approval routing, exceptions, ERP integration, compliance, auditability, and ongoing monitoring. That is where many internal build projects become difficult to scale and maintain.
Accounts payable automation software is designed to manage the end-to-end AP process, including invoice capture, matching, approvals, posting, and often payment controls, within a production-ready environment. A custom-built AP solution may begin with the same goals, but the business must usually take responsibility for system design, integration maintenance, security, governance, monitoring, and adaptation as requirements change. In practice, the difference is not just functionality. It is also who owns the operational burden over time.
PO matching sounds simple, but in real AP environments it is one of the hardest parts of the workflow. Invoices often involve partial deliveries, pricing differences, line-level discrepancies, exceptions, and supplier-specific variations. That means successful matching depends on more than extracting invoice data correctly. It requires specialised logic, historical learning, and deep domain knowledge to achieve reliable accuracy at scale.
The hidden costs of building AP automation in-house usually appear after the initial build. These include maintaining ERP and API integrations, adapting to regulatory changes, monitoring system performance, fixing issues before they disrupt supplier payments, managing model drift, and supporting security and compliance requirements on an ongoing basis. A proof of concept may look cost-effective at first, but the long-term cost of ownership is often much higher than expected once production realities are included.
No. AI can significantly improve invoice processing, especially in areas like document understanding, extraction, and workflow assistance, but end-to-end accounts payable automation requires more than a capable model. It also depends on controls, approvals, matching logic, exception handling, ERP connectivity, audit trails, and compliance safeguards. In other words, AI can accelerate AP automation, but it does not remove the need for finance-grade system design and governance.
