In Part 1, I looked at what it actually takes to build an AI-powered AP automation system internally: the technical complexity beyond data extraction, the compliance foundations that can’t be deferred, and the operational burden that only becomes visible after deployment.
This second article picks up where that left off. Because even if an organisation builds something that works, the harder question remains: can you run it? Can you keep it secure, keep it auditable, keep it accurate, and keep it cost-effective over time?
That’s the question most build conversations don’t get to. And it’s the one that matters most.
Auditability: every decision must be logged
In accounts payable, auditability isn’t a feature. It’s a foundational requirement.
Every action that happens within the invoice processing pipeline needs to be logged. Every decision the system makes, every routing step, every approval, every exception. All of it needs to be recorded for audit purposes. And critically, that record needs to be immutable. You can’t have someone going back and altering it after the fact. It’s write-once, then left as-is.
This isn’t a nice-to-have layer that gets added once the core system is working. It needs to be engineered into the architecture from the start. And the compliance infrastructure around it needs to be certified. At SoftCo, we’re audited ourselves to ensure that our trails, processes and controls meet a very high standard. Taking that responsibility in-house transfers significant compliance risk and cost to the organisation.
The regulatory direction is making this more demanding, not less. The EU AI Act, which comes into full effect for high-risk systems by August 2026, requires lifecycle risk management, documented oversight, transparency and conformity assessments for AI systems operating in high-risk contexts. Financial process automation sits squarely within that scope. And the Financial Stability Board’s 2025 monitoring report warns that AI adoption without appropriate controls could amplify financial vulnerabilities across the sector.
The message from regulators is consistent: auditability and governance aren’t becoming optional. They’re becoming legally mandated. Any organisation building its own AP automation needs to account for this from day one.
Security: LLM data exposure and access control
Security in AI-powered AP systems operates on multiple levels, and each one introduces risk that needs to be actively managed.
The most visible concern is data exposure through third-party LLMs. You need to be very careful about what you’re doing with financial data, and sending it to external providers is inherently a risk. A naive implementation might use free-tier LLM services where data could potentially be fed back into model training. That’s data leakage, and it’s exactly the kind of risk that’s easy to overlook in a prototype but unacceptable in production.
Even with paid, enterprise-grade models, the basics still apply. Data needs to be encrypted in transit and at rest. But it’s not just about the external API call. All of the data within whatever system you’re building needs to be kept secure. Access control matters just as much. The principle of least permissions applies to every system and every user in the pipeline: your automation should only have access to the bare minimum it needs to do its job.
Here’s the practical reality. Apart from very large organisations, few companies have dedicated security expertise in-house. It’s a very specialised role, but many organisations considering an internal build won’t be in a position to recruit for one.
Guidance from the NIST AI Risk Management Framework reinforces the need for role differentiation, cybersecurity integration and access controls within AI architectures. And finance leaders are increasingly focused on embedding these controls into AI systems rather than treating them as afterthoughts. These aren’t aspirational standards. They’re the operating baseline for any system handling financial data.
The true cost of ownership
When organisations evaluate a build decision, the initial development cost is usually the number they focus on. But total cost of ownership extends well beyond that first phase, and the ongoing cost centres are both real and cumulative.
There’s monitoring infrastructure. Compliance maintenance. Software maintenance for whatever you’ve built. ERP integration upkeep. And continuous handling of edge cases.
- Edge cases. If you build your own system, it’ll likely be designed for the 90% of invoices that follow standard patterns. But then there’s another 10 to 20% that are more varied, more exception-heavy, more difficult. You need to continue adapting your software to handle those. At SoftCo, we’ve already worked through those problems across years of deployment in complex organisations.
- People. To build and run this properly, you need people covering at least five distinct functions: software engineering for ongoing development and maintenance, operations and monitoring, security expertise, user support (the equivalent of customer success and technical support teams), and domain experts who understand the AP process deeply enough to guide the engineering decisions. Domain expertise is a huge factor here. If you don’t have it in-house, you’re going to struggle to do this the right way.
- Key-person risk. In engineering, we sometimes call it the bus factor: how many people need to be unavailable before the organisation loses critical knowledge of how the system works? You don’t just need breadth of coverage. You need depth, backup, a maintained knowledge base, handover processes and onboarding documentation. Without that, a single departure can leave a critical financial system without anyone who fully understands it.
The broader picture supports this. 67% of data leaders report struggling to transition GenAI pilots to production, with more than half citing data reliability as a key barrier. As The Economist has observed, enterprise AI is entering a phase where enthusiasm meets the harder realities of integration, governance and cost control. For finance leaders, the question isn’t whether you can build this. It’s what it will truly cost to run and govern it over time.
The domain knowledge gap
This is the point I want to be most direct about.
From the outside, AP looks like a data-shuffling exercise. Extract information from a PDF, do a bit of matching, decide whether to pay, transfer the data to the ERP. It’s tidy on a whiteboard. In production, it’s anything but.
Each step along the way is complex in practice, especially matching and coding invoices correctly. When you’re processing high volumes, any mistakes in those areas add up. And what they add up to is manual handling: people stepping in to review, correct and resolve what the automation couldn’t. That’s the opposite of what the system was supposed to deliver.
Without domain knowledge built into the system, you get a high volume of exceptions. The automation encounters something it doesn’t know how to handle, an unexpected variation, an edge case it wasn’t designed for, and at least one person has to step in and figure out what’s going on. At scale, this doesn’t just slow things down. It reverses the efficiency gains entirely.
The downstream consequences are tangible. Delayed payments to suppliers rack up penalties. On the other side, you miss opportunities for early-payment discounts that represent real, recurring savings. There’s a lot hidden beneath the surface that makes this harder than it appears, and the cost of getting it wrong compounds over time.
Finance leaders are investing heavily in automation, with 87% of CFOs rating AI as critically important and nearly half citing process automation as their top talent priority. The intent is clear. But intent without domain expertise in the execution layer leads to more exceptions, more manual intervention and more cost, not less.
AI doesn’t remove complexity. It exposes it.
When building makes sense
It’s important to be balanced about this, because in some cases building internally can genuinely make sense.
Very large organisations with established software engineering departments, specific requirements that most vendors can’t meet out of the box, and mature cloud infrastructure may have legitimate reasons to invest in an internal build. If you already have the skills, the infrastructure and a genuinely unique set of requirements, there can be a case for it.
But even then, there’s an opportunity cost that deserves scrutiny. What could those software teams be building if they weren’t replicating a capability that specialists already provide? And the criteria for a credible internal build are high: significant scale, deep in-house engineering capability, mature cloud environments, and often the organisation is in the software domain itself.
The broader market suggests the direction of travel. A 2025 survey of enterprise CIOs reports a marked shift over the past twelve months from building internal GenAI applications toward buying third-party solutions, as off-the-shelf offerings mature and custom builds prove difficult to sustain. Gartner’s 2024 AI survey found that 43% of enterprise AI capability already comes from vendor-embedded solutions, with that share growing rapidly.
For most organisations, especially in the mid-market, the risk and cost calculus favours working with domain specialists who’ve already solved these problems at scale.
Why enterprise AI platforms exist
Everything across both articles leads to a single conclusion. Building an AI-powered AP system is technically possible. The tools exist. The barriers to getting started are lower than they’ve ever been. None of that is in question.
What’s in question is whether an organisation can sustain it. Specifically, can it:
- Maintain the integrations as ERPs and third-party systems evolve?
- Manage the security posture across every layer of the stack?
- Satisfy audit requirements with immutable, certified logging?
- Handle the edge cases that standard patterns don’t cover?
- Retain the domain knowledge the system depends on?
- Absorb the compliance burden as regulation tightens?
- Keep the system running reliably under the pressure of real financial deadlines?
Specialist platforms exist because they’ve already done this work. The matching logic, the compliance certifications, the ERP integrations, the exception handling, the monitoring infrastructure. These are solved problems, built up through years of deployment across complex, multi-entity, multi-jurisdiction environments.
At SoftCo, we know this domain. We’ve already worked through the difficult problems. What we’re focused on now is applying new AI capabilities to make the process better, more accurate and more efficient across the entire pipeline.
The question organisations should be asking isn’t whether they can build it. It’s where their teams can add the most value. Is it in replicating work that domain specialists already do well, or is it elsewhere?
We specialise in tailoring automation to each customer’s specific needs: their controls, their governance, their tax rules, their ERP architecture. Complexity isn’t an edge case. It’s the operating reality. And automation needs to be shaped around it, not the other way around.
AI makes building easier. Financial accountability makes it harder. The decision to build or buy sits at that intersection, and it calls for more scrutiny than the “let’s just build it ourselves” narrative suggests.
Frequently Asked Questions
The total cost of ownership of AP automation goes far beyond the initial build or software fee. It includes monitoring, compliance maintenance, security controls, ERP integration upkeep, support, software maintenance, and the ongoing work needed to handle exceptions and edge cases. For organisations building in-house, these costs often grow over time because the responsibility for running and governing the system never really stops
AP automation needs a strong audit trail because every action in the invoice process must be visible, traceable, and reviewable. That includes approvals, routing decisions, exceptions, and system-generated actions. In finance, auditability is not an optional extra. It is a core requirement for compliance, control, and trust in the system.
The main security risks in AI-powered AP automation include financial data exposure through third-party models, weak access controls, over-permissioned systems, and poor protection of data in transit and at rest. These risks become more serious when organisations move from prototype to production, because the system is then handling real invoices, supplier data, and payment-related information.
That depends on the organisation’s scale, engineering capability, cloud maturity, and internal AP expertise. Very large organisations with highly specific requirements may have a case for building. But for most businesses, buying specialist accounts payable automation software is the lower-risk option because the vendor has already solved for auditability, security, integrations, exception handling, and long-term operational support.
AI invoice processing can look simple at the proof-of-concept stage, but governing it in production is much harder. Organisations need to manage logging, controls, security, model behaviour, compliance requirements, support processes, and knowledge transfer over time. Without that governance layer, the result is usually more exceptions, more manual intervention, and more cost instead of less.
