‍

An ERP can be doing exactly what it was designed to do and still be the wrong place to run a complex financial workflow.

That distinction matters.

Modern ERP platforms are sophisticated. Microsoft Dynamics 365 supports configurable approval workflows, conditions, escalation and final approvers. SAP S/4HANA provides flexible workflows for areas such as purchase requisitions, purchase orders and supplier invoices. Oracle Fusion Financials supports configurable approval processes across payments, invoices and other financial activities.

The problem is therefore not that ERPs cannot manage workflows.

The problem appears when a financial process extends beyond the assumptions, objects and boundaries of the ERP.

A bank may need a payment request to pass through several business units before being executed through separate banking infrastructure.

An insurer may need a disbursement workflow to incorporate claims data, approval authorities, external beneficiaries and reconciliation.

A multi-country enterprise may need different approval rules, currencies, banks, subsidiaries and documentation requirements while still maintaining one group accounting environment.

At that point, the organisation faces a choice.

It can keep modifying the ERP until the workflow fits.

It can move important parts of the process into spreadsheets and email.

Or it can allow the ERP to remain the system of record while building a financial workflow around it.

For many complex finance operations, the third option is the most useful.

‍

The ERP is often not failing. The workflow is crossing the ERP boundary.

An ERP is particularly good at creating standardisation.

It provides structure around areas such as:

• Accounting
• Procurement
• Accounts payable
• General ledger
• Budgeting
• Inventory
• Fixed assets
• Financial reporting

But many important finance processes are no longer contained within those boundaries.

Consider a large supplier payment.

The accounting entry may belong in the ERP.

But the complete process could involve a request created by an employee, validation against a departmental budget, approval by two managers, additional treasury approval above a threshold, vendor-account verification, payment through a bank or payment provider, transaction-status confirmation, collection of supporting documents, reconciliation against the bank statement and final posting back into accounting.

The ERP may participate in that process without being the natural home for every step.

The more systems, participants and exceptions involved, the more important that distinction becomes.

‍

Where standard ERP workflows become difficult

The point at which an organisation outgrows an ERP workflow is usually not determined by transaction volume alone.

It is determined by workflow complexity.

A workflow becomes more difficult when several conditions occur together: authority depends on multiple variables; external systems participate in execution; different entities follow different policies; supporting documentation varies by transaction type; exceptions require investigation; and management needs operational visibility before the transaction reaches accounting.

This is where organisations often begin building workarounds.

The accounting system records the final transaction correctly, but the process before and after that entry happens through spreadsheets, email, shared folders, messaging applications and separate banking portals.

The organisation therefore has an ERP without having an end-to-end financial workflow.

‍

1. ERP workflows are usually strongest inside their own transaction model

ERP workflows operate around objects and processes the platform understands.

A purchase requisition becomes a purchase order.

An invoice goes through review and approval.

A journal is submitted and approved.

A payment batch enters an approval process.

This is useful because the ERP understands the underlying transaction.

Microsoft, SAP and Oracle all provide extensive configuration for these kinds of workflows.

Complexity appears when the organisation's process does not begin or end with the ERP object.

A request may originate in another application.

Approval may depend on information from several systems.

Payment may happen outside the ERP.

The result may need to return from a bank before the transaction can be considered complete.

An exception may require operations to investigate data that exists outside accounting.

The ERP can still store the financial record.

But operating the entire workflow inside it may require increasingly specialised configuration or customisation.

‍

2. Approval logic can become more complex than an approval chain

A simple approval workflow asks:

Who needs to approve this?

A complex financial workflow asks considerably more.

It may need to determine whether approval depends on the amount, department, branch, legal entity, project, expense type, available budget, currency, destination, beneficiary type or risk category.

The workflow may also need to behave differently if an approver is unavailable, the amount changes after approval, supporting documents are incomplete or the transaction has already passed one control point.

Major ERP systems provide sophisticated approval functionality. For example, Dynamics 365 supports conditional approval steps, assignment rules and overdue behaviour, while SAP flexible workflows can support one-step or multi-step approval structures.

The question is not whether such rules can be configured.

The question is whether the ERP remains the most maintainable place to represent an organisation's entire authority model as complexity increases.

When every policy change requires specialised ERP configuration, testing and deployment, the approval process can become harder to change than the business itself.

‍

3. Payment execution frequently happens outside the ERP

Accounting software and payment infrastructure perform different jobs.

The ERP may determine that a liability exists.

The bank, payment switch, mobile money provider or payment service provider actually moves the money.

This distinction is particularly important in African markets where financial institutions and enterprises operate through increasingly interconnected payment environments.

Nigeria's current Payments System Vision 2028 explicitly emphasises interoperability and interconnectivity. South Africa's Payments Ecosystem Modernisation Programme is likewise designed around more interoperable digital payment infrastructure. Ghana continues to deepen interoperability across payment platforms, while Kenya's banking sector has increasingly adopted APIs and third-party technology.

This creates a workflow boundary.

The ERP may approve the accounting transaction while another platform executes it.

The organisation then needs to answer:

Did the payment reach the bank?

Was it accepted?

Did it fail?

Was it reversed?

Did the beneficiary receive it?

Was the amount different?

Has it settled?

Has it been reconciled?

A traditional ERP transaction status does not automatically represent the complete lifecycle of money moving across external financial infrastructure.

‍

4. The difficult part of finance is often the exception

Standard software demonstrations naturally show the standard process.

Request.

Approve.

Pay.

Record.

Real finance operations spend a significant amount of time on transactions that do not follow that path.

A beneficiary account changes.

A bank rejects the payment.

A transaction times out.

A duplicate appears.

The amount paid differs from the approved amount.

A supporting document is missing.

A transaction appears at the bank but not in the accounting system.

One system reports success while another reports pending.

These are not necessarily ERP problems.

They are operational exception problems.

A mature financial workflow needs to turn each exception into something manageable: a reason, an owner, a status, supporting evidence, a next action and a resolution history.

When this capability is weak, finance teams often create an exception-management system themselves using spreadsheets, email and messaging applications.

That is one of the clearest signs that the organisation needs a workflow layer around its ERP.

‍

5. Reconciliation reaches beyond accounting

An ERP can contain the accounting record.

Reconciliation asks whether that record agrees with what happened elsewhere.

That may require comparison against bank records, payment processors, wallets, card systems, subsidiaries, customer platforms or another operational database.

The challenge therefore is not merely producing a ledger entry.

It is connecting multiple representations of the same economic event.

A good reconciliation workflow needs to know what matched, what did not, why the difference exists, who owns the exception and what evidence closed it.

When reconciliation depends on downloading several reports and comparing them outside the ERP, the organisation has found another boundary where a dedicated workflow may provide more value than additional ERP customisation.

‍

6. External users do not always belong inside the ERP

Financial processes increasingly involve people who are not finance-system users.

They may include:

• Suppliers
• Customers
• Agents
• Merchants
• Contractors
• Partners
• Branch operators
• Field teams

Giving every participant direct access to the ERP may be unnecessary, expensive or inappropriate.

Instead, the organisation may need a portal through which an external party can submit information, see status, upload documents or respond to an exception.

The ERP remains behind the process.

The portal becomes the interaction layer.

This separation can also improve the user experience because an external supplier does not need to understand the organisation's internal accounting structure simply to submit an invoice or check a payment status.

‍

7. Multi-country operations introduce another layer of variation

A group operating across Nigeria, South Africa, Kenya and Ghana may want one financial control model without forcing every market into an identical operational process.

Local differences can include:

• Banks and payment providers
• Settlement arrangements
• Currencies
• Tax requirements
• Documentation
• Approval structures
• Business entities
• Customer channels
• Regulatory reporting
• Data-protection requirements

The ERP may provide group-level accounting consistency.

The workflow around it may need to accommodate local execution.

That distinction becomes increasingly valuable as an organisation expands.

Instead of heavily customising the ERP separately for every country, a configurable workflow layer can represent country-specific rules while preserving a common financial record underneath.

‍

8. Heavy ERP customisation creates its own operating cost

When a standard ERP does not match a workflow, customisation is an obvious response.

Some customisation is entirely appropriate.

The problem appears when every operational requirement becomes an ERP modification.

Over time, the institution may accumulate:

• Custom approval rules
• Custom screens
• Bespoke integrations
• Custom reports
• Special data fields
• Country-specific modifications
• Custom exception processes

Each addition may be justified individually.

Together, they can make upgrades, testing and future changes harder.

Even ERP vendors increasingly provide extensibility tools and external workflow capabilities rather than assuming every process must live inside the core application. Microsoft, for example, supports Power Automate integrations with Dynamics 365 workflows and business events.

The more useful architectural question is:

Does this requirement belong inside the ERP, or should the ERP expose the data and transaction capability that another workflow needs?

‍

The Flex ERP Boundary Framework

Flex recommends evaluating financial processes across four layers:

‍

Simple processes may keep all four layers close to the ERP.

Complex processes tend to separate them.

The mistake is assuming that separation automatically means fragmentation.

A well-designed architecture can connect the layers while giving each system responsibility for the job it performs best.

‍

When you should configure the ERP instead

Not every difficult workflow justifies custom software.

If the requirement fits cleanly within functionality already supported by the ERP, configuration is usually preferable.

An organisation should first ask:

Can the ERP support this using standard configuration without compromising the process?

If yes, use it.

SAP, Oracle and Microsoft have invested heavily in configurable workflows precisely so organisations do not need to develop custom applications for ordinary approval and finance processes.

A separate workflow becomes more compelling when the process is highly distinctive, crosses several systems, involves substantial external interaction, requires specialised exception handling or changes frequently enough that ERP customisation becomes an obstacle.

‍

When to add a workflow layer around the ERP

The strongest signal is not that the finance team dislikes the ERP.

It is that important parts of the process have escaped it.

If an organisation has an ERP but employees still need spreadsheets to track approvals, messaging applications to resolve exceptions, separate portals to check payment status and manual uploads to connect the bank to accounting, the problem is not necessarily the ERP.

The missing capability is the process connecting everything together.

A workflow layer can sit between users, financial infrastructure and the ERP.

For example:

Request → approval → payment execution → status → reconciliation → ERP

The ERP remains the accounting system of record.

The workflow becomes the operating environment around the financial transaction.

‍

A practical example: supplier payments

Consider a multi-entity company using a mature ERP.

The ERP already manages suppliers, purchase orders, invoices and the general ledger.

But the organisation has a complicated payment operation.

Different subsidiaries have different approval authorities.

Large payments require treasury approval.

Some payments are executed through different banks depending on currency.

Supporting documents vary by payment type.

Finance needs real-time payment status.

Failed transactions must be investigated.

Completed transactions must be reconciled automatically before accounting is considered complete.

The organisation has three options.

‍

Option 1: Force everything into the ERP

This may work if the ERP supports the complete requirement cleanly.

If it requires extensive customisation across approvals, payment integrations, exception screens and country specific processes, the ERP implementation may become increasingly difficult to maintain.

‍

Option 2: Keep the ERP and operate around it manually

This is common.

The ERP handles accounting while spreadsheets, email, banking portals and manual reconciliation complete the process.

The software cost may appear lower, but the organisation absorbs the operational cost.

‍

Option 3: Keep the ERP and build the missing workflow

The ERP continues managing suppliers, invoices and financial records.

A workflow layer handles request initiation, dynamic approvals, payment orchestration, status tracking, supporting evidence and reconciliation.

Once the transaction is complete, the relevant information returns to the ERP.

This preserves the value of the ERP without requiring it to perform every operational role.

‍

Why this matters particularly in African financial operations

The case for connected workflows becomes stronger as financial infrastructure becomes more interconnected.

‍

Nigeria

Nigeria's Payments System Vision 2028 is explicitly built around interoperability, security, innovation and collaboration.

For enterprises and financial institutions, this increasingly means finance processes may interact with banks, payment companies and other financial infrastructure outside the ERP.

The ability to connect those services into one controlled operating workflow becomes strategically useful.

‍

South Africa

SARB's current Payments Ecosystem Modernisation Programme seeks to create a more interoperable digital payments environment, including new shared infrastructure and broader participation.

Large South African enterprises may therefore find that the ERP remains central to accounting while payment execution and operational workflows become increasingly connected to external systems.

‍

Kenya

Kenya provides perhaps the clearest evidence of this trend. The Central Bank of Kenya reported that 75% of surveyed financial institutions had adopted API technology in its 2024 innovation survey. Its 2025 survey also found operational and third-party risk becoming increasingly important as banking systems become more digital and interconnected.

An ERP cannot be evaluated only by what happens inside it when the wider financial operation increasingly depends on APIs and external services.

‍

Ghana

The Bank of Ghana has highlighted deeper interoperability across payment platforms, while its National Payment Systems Strategy 2025–2029 provides a roadmap around areas including interoperability, instant payments, cybersecurity and modernization.

For Ghanaian organisations, the same architectural principle applies: preserve the ERP as the financial record where appropriate, while building the integrations and workflow required to connect it to a changing payments environment.

‍

Do not replace a good ERP to solve a workflow problem

This may be the most important point.

If the ERP performs accounting, reporting and enterprise resource planning well, replacing it because payment approvals or reconciliation are difficult can create a much larger transformation project than necessary.

The organisation should first identify the layer that is actually failing.

Is it:

Record?

Then the ERP itself may require attention.

Control?

The approval architecture may need redesign.

Execution?

The bank or payment integration may be the issue.

Operations?

The missing capability may be status tracking, reconciliation, exception management or a portal.

The correct intervention should match the failing layer.

‍

Where Flex Enterprise Solutions fits

‍

Flex Enterprise Solutions works at the point where financial workflows become more complex than the standard process inside an ERP.

Flex can build systems around:

• Payment requests and disbursements
• Multi-level and conditional approvals
• Reconciliation and exception management
• Operational dashboards
• Customer, supplier and partner portals
• Banking and payment integrations
• ERP and accounting integrations
• Custom finance workflows

The objective is not to replace ERP systems that are already performing their role.

It is to connect them to the operational processes they cannot, or should not, carry alone.

A Flex implementation might therefore leave SAP, Oracle, Dynamics, Sage, Odoo or another enterprise system responsible for the financial record while Flex manages the workflow surrounding approval, execution, status, evidence and reconciliation.

The specific architecture should depend on the institution's existing systems and requirements, rather than assuming one model fits every organisation.

‍

The ERP should remain where it is strongest

The conversation about ERP limitations often becomes unnecessarily binary.

Either the organisation accepts the standard process or replaces the ERP with custom software.

There is a third option.

Keep the ERP for what it does well. Build the missing financial operating layer around it.

That approach allows organisations to preserve years of investment in accounting, master data, controls and reporting while changing the part of the process that is actually creating friction.

For complex financial workflows, the best architecture is often not one system doing everything.

It is several systems with clearly defined responsibilities operating as one coherent process.

‍

Frequently Asked Questions

‍

Why do ERP systems struggle with complex financial workflows?

ERPs are designed to standardise and record enterprise processes, and leading platforms support sophisticated configurable workflows. Problems arise when a financial process spans several external systems, highly specialised approval rules, payment execution, exception management, reconciliation or external users that do not fit cleanly within the ERP's standard transaction model.

‍

Does this mean an ERP should not be used for approvals?

No. Standard ERP approval functionality is often the best option when the workflow fits the platform cleanly. A separate workflow layer becomes more useful when approval logic depends on many external data points, changes frequently or must coordinate actions outside the ERP.

‍

Should a company replace its ERP when finance teams rely heavily on spreadsheets?

Not automatically. First determine why spreadsheets exist. They may be filling gaps in approvals, reconciliation, exception management, operational reporting or system integration. Addressing those gaps may be more practical than replacing the ERP itself.

‍

Can custom financial software integrate with an existing ERP?

Yes, provided the ERP and surrounding systems offer appropriate integration methods. A custom workflow can manage operational activities while sending or receiving the information required to keep the ERP's financial records current.

‍

Can an ERP connect directly to banks and payment providers?

Many ERP platforms support bank and payment integrations. The practical question is whether those standard integrations support the institution's specific banks, payment providers, transaction states, controls, reconciliation requirements and local-market infrastructure.

‍

What is a finance workflow layer?

A finance workflow layer is software that coordinates a financial process across users and systems. It can manage requests, approvals, payment execution, status, documentation, exceptions and reconciliation while allowing the ERP to remain the underlying system of financial record.

‍

When is ERP customisation better than separate workflow software?

ERP customisation is appropriate when the requirement remains close to the ERP's standard processes, can be maintained cleanly and does not create unnecessary upgrade or integration complexity. A separate layer becomes more attractive as the workflow crosses more systems or develops substantially different operational requirements.

‍

Can one workflow layer support multiple African countries?

Potentially. A well-designed system can maintain common group-level controls while allowing country-specific integrations, currencies, entities and workflow rules. The exact architecture depends on the operating and regulatory requirements of each market.

‍

How can Flex work with an organisation's existing ERP?

Flex Enterprise Solutions can build approval, payment, reconciliation, portal, reporting and integration workflows around existing enterprise and accounting systems. The objective is to preserve systems that work while building the missing operational layer required to connect the complete financial process.

‍