When core finance systems go down, most organizations discover the same thing: the intention to keep paying suppliers and employees was never the problem. The problem was whether they could still do it with the right controls, the right data, and the right approvals.
That is why payment continuity should not be treated as an emergency workaround. It is a finance resilience capability, and it sits at the intersection of accounts payable, treasury, IT, security, and internal control.
Across our implementations with large organizations, this challenge consistently breaks down into four phases.
In normal operations, the ERP holds thousands of open invoices. When it goes down, so does visibility over all of them. The first phase addresses a deceptively simple question: in a crisis window with limited capacity, what actually needs to be paid, and to whom?
Two things must be solved in advance.
The output is a clean, filtered payment list with all relevant vendor data attached.
The data design question is not whether to automate extraction. The real decisions are more granular: what refresh frequency and daily cut-off time is appropriate for each type of record? Invoice data captured at end-of-day may already be incomplete by the following morning if a crisis hits mid-cycle. Vendor master data, which changes less frequently, may warrant a different cadence. These parameters need to be set deliberately, per data type, and validated against actual payment cycles.
The second constraint is fraud. A crisis is exactly when social engineering attacks on payment data spike. Vendor bank details stored in the process must be treated as frozen and authoritative. Any request to override them, however plausible it sounds, needs a dedicated validation process.
Phase 1 produces a list. Phase 2 is where it is reviewed critically before any payment is committed. The team's focus should be accuracy and fraud prevention.
Not all invoices should be treated the same way. Invoices already registered and validated in the ERP before the crisis carry an implicit assurance: the normal matching process ran against them. These can move through review quickly, with checks focused on vendor banking details and amounts. Invoices not previously validated require a full dedicated review: supporting documentation (purchase order, service contract, delivery note) must be checked manually, and any invoice that cannot be validated against a source document gets parked. Parking is not rejection, it means the invoice is set aside with a reason recorded, to be reprocessed in a later run or after systems are restored.
This distinction matters because speed and control are in tension during a crisis. If the process is too heavy, payments stall. If it is too loose, the organization creates fraud risk, control gaps, or downstream reconciliation issues.
The most important control in this phase is the four-eyes principle: the person who prepared the payment list cannot be the person who approves it. The payment proposal, a formal document listing exactly what will be paid, to whom, for how much, must be signed off by a second authorized person before anything proceeds, with a timestamped record.
The four-eyes principle is straightforward in theory but can fail if key people are unavailable because of the crisis. The delegation chain must be defined in advance: who is the backup, what is the backup's backup, is this formally documented?
A second design question is documentation availability for unvalidated invoices. If purchase orders and contracts are only accessible through the ERP, deciding which documents, for which vendor categories, should be pre-stored in the process, and who keeps them current, is a decision that must happen before any crisis.
A third design consideration is process variation across the organization. In practice, payment urgency criteria and approval requirements may not be uniform across business units. This is not a problem in itself, but it needs to be designed deliberately. A single rigid process applied across all contexts often fails because it does not reflect how decisions are actually made. Defining these variations in advance is part of what makes the process executable under pressure.
An approved payment proposal is not a payment. Phase 3 is where the proposal becomes a bank submission.
Before any submission begins, there is one mandatory checkpoint: confirming that sufficient cash is available to cover the proposal. The Treasury team must confirm cash availability based on their own crisis-time access to banking information. If Treasury cannot confirm availability, or decides conditions are not right to proceed, execution does not begin. This is a hard gate, and the decision rests explicitly with Treasury.
Once the go-ahead is given, the first decision is which payment channel to use. The channel determines the required exchange format: banks accept payments in specific batch formats (SEPA XML, PAIN.001, or proprietary CSV depending on the institution). Whatever channel is selected, a four-eyes control must be operational at submission, either enforced natively by the banking portal through dual authorization, or built explicitly into the process itself if the channel does not support it.
Design for the worst case: both ERP and TMS are unavailable. If the process works under those conditions, it will work under any conditions. Under this assumption, the payment channel question becomes critical. Based on the work conducted with Treasury professionals in the Treasury Resilience and Efficiency Taskforce, the recommendation is to formally set up crisis-activated eBanking with a limited number of pre-selected banking partners, and for larger organizations, across up to three banks to avoid single-point dependency.
Bank file format is also regularly underestimated. In our projects, format mismatches and untested templates are common execution failures encountered during drills.
A payment submitted is not a payment confirmed. Phase 4 ensures the crisis period can be cleanly closed.
The immediate task is matching every payment against a bank confirmation that funds have left the account. Rejections (wrong IBAN, closed account, transaction limit, sanctions flag) must be identified and explicitly resolved: correct and resubmit, escalate, or park.
Everything that happened during the crisis must then be captured in an audit package: the original data extract, scoring decisions, parking log, approved payment proposal, and all submission and confirmation records. This demonstrates to internal audit and regulators that controls were maintained, and provides the evidence base for any vendor dispute. The audit package should be a natural output of each phase as it runs.
Finally, when systems come back online, crisis-period payments must be reconciled against what the ERP still shows as open. Without this step, invoices paid manually during the crisis would be processed again once the ERP is restored. The rehydration file format should be agreed with the ERP team before any crisis occurs, with a named owner on both sides.
This closing phase is what turns a crisis payment run into a controlled, auditable business process rather than an operational workaround.
The four phases described here are not complicated. What makes them hard is that every decision they require must be made, documented, and tested before a crisis happens. Under pressure, teams default to improvisation. Improvisation in payments leads to errors, fraud exposure, and reconciliation backlogs that outlast the incident itself.
The question for any finance organization is not whether it could figure this out under pressure. It is whether it wants to.