Instruction, posting, execution, rejection or return and reconciliation handled as distinct states of one route — each with its own source, its own owner and the confirmation that makes it real.
01 · The problem
A payment run is approved on Tuesday. By Thursday the supplier is asking about its transfer, accounting is looking at a charge nobody recognizes, and treasury is trying to establish whether the file was ever submitted. Three different questions, and not one of them is answered in the same place.
This lands on treasury and accounts payable, and it comes back every cycle: when the run goes out, when the channel sends something back, and when the period has to be closed. Accounting and financial control inherit the tail end of it, with items nobody can explain without reconstructing the trail one conversation at a time.
Follow-up is pieced together from whatever is at hand: Microsoft Excel spreadsheets holding the payment run and its notes, email chasing a remittance advice or flagging a returned item, and Microsoft Power BI reporting on the outstanding balance. Each piece serves a useful purpose, and none of them records who raised the instruction, who approved it, what the payment channel sent back, and what was finally reconciled.
Showing financial status does not, by itself, produce a reconciliation process: a dashboard reports the balance, and the route that carries each payment to its confirmation is still missing.
02 · The solution
The route pulls apart what travels together in practice: the payment instruction, its posting in the system of record, execution through the agreed channel, the rejection or return when one occurs, and reconciliation against the movement that actually hit the account. Each state has its own source, its own owner and its own evidence, and none of them is assumed just because the previous one moved.
The route is built on the approved definitions in the Operational Graph: every instruction stays connected to the document behind it, the legal entity, the funding account, the payee and the authorized approver for that band. BPMflow runs the case work — queues, assignment, deadlines, approvals and evidence — so the process grows out of the graph rather than out of a diagram drawn on the side.
An invoice exception is what comes before this route: while the difference is unresolved and unapproved, there is no instruction to raise — that work sits in Invoice Exception Resolution. The supplier asks after the status of its payment through Supplier Service Desk for Shared Services, and when the disbursement traces back to a budget approval, that history comes from Finance Shared Services — Budget Approval Workflow.
03 · Capabilities
Instructions sit in a single queue, with their state, their confirming source, their age and any pending approval in plain view. Max answers about the case within the authorized context: it explains which state the payment is in, shows the evidence on record and points to the next owner.
Opens the case from an approved invoice, a scheduled payment run, an agreed advance, an approved expense claim or a one-off instruction, with the supporting document in view.
Applies the rule that fits the amount, the legal entity and the account being drawn on, and keeps the approval with its author and timestamp.
A change to a payee's bank details is treated as a separate event, verified through the channel and by the people the organization designates. Reviewing a document is not, on its own, proof of account ownership.
Records what was submitted, when, and through which channel, together with the acknowledgement or reference number returned by the authorized source.
Classifies the reason sent back — invalid account, payee under review, limit exceeded, withholding applied — routes it to whoever can correct it, and reopens approval when the underlying detail changes.
Matches the bank movement to the instruction and the source document, and turns unmatched or disputed items into assigned work with an owner and a deadline.
04 · Confirmation by state
There is no single sign-off across the whole route. Each state counts as reached on the evidence and the source agreed for that event: sometimes the answer comes from the system of record, sometimes from the person holding the authority.
01
Source
The document behind it — an approved invoice, a payment run, a contract or a request — together with the approval rule that applies.
Who or what confirms it
The authorized approver for that band, with the approval on record. Before that point there is a request, not an instruction.
02
Source
The ERP or the treasury system where the payment order is booked.
Who or what confirms it
That system itself, through the document number and status it returns. An approval that never got booked is still outstanding.
03
Source
The payment channel the organization has arranged with its bank.
Who or what confirms it
The explicit execution status that channel sends back, or the matching movement in the authorized source. An acknowledgement of receipt confirms submission, not execution. EAFlow neither executes the payment nor stands in for that channel.
04
Source
The reason code returned by the channel, or the finding raised when the account movements are reviewed.
Who or what confirms it
Whoever puts the reason on record: the channel when it reports one, or the treasury analyst when they spot it. Either way the case reopens.
05
Source
The bank statement or account movement file, matched against the instruction and the source document.
Who or what confirms it
The reconciliation owner, and the accounting close when the organization requires it for that period.
05 · Roles
One payment passes through several pairs of hands, and each is accountable for a different leg of the route. None of them signs off the states belonging to the others, and that separation is what makes it possible to see where a payment stopped without asking around.
Builds the payment run and carries the case to closure.
What they see
Each payment route by state, due date, legal entity, funding account and channel, each with its supporting document.
What they do
Prepares the request, sends it for approval, submits it through the agreed channel, and records the acknowledgement, rejection or return.
Approves within the limits assigned to them.
What they see
The requests waiting at their band, with the source document, the payee, the account and the amount at stake.
What they do
Approves, rejects or sends it back with a query. The decision to disburse stays with the organization.
Closes the loop against what actually moved.
What they see
The period's movements with their matching instruction, and the items that still have neither a document nor an explanation.
What they do
Matches the movement to the instruction and the document, raises the difference as a case, and confirms the reconciliation for the period.
Fixes the detail or the document holding up their payment.
What they see
The status of the payment that concerns them and what is still missing, in their own case and with scoped access.
What they do
Answers the query, updates their documentation and follows progress without calling every department in turn.
06 · Implementation
The work starts from the process as it runs today: the minimum context for the first payment type is enough, with no prior architecture project and no change to the channel the organization has already arranged with its bank. Scope follows payment type rather than volume — a cycle of very few transactions can hold the whole error risk of the period.
1 · Agree on the outcome
Which payments are in scope, which rule approves each band, what evidence closes each state, and who or which system confirms it in this organization.
2 · Wire up the source behind each state
Picks up the source document and the payment order from the ERP and the treasury system, and takes the acknowledgement and the movement from the channel and the statement agreed as the authorized source.
3 · Prove the route and hand it over
The team runs a live payment cycle through to reconciliation, tunes the rules, rejection reasons and deadlines, then keeps daily operation under the client team's control.
07 · Typical scenarios
Several legal entities, several funding accounts and more than one channel; scheduled runs sitting alongside urgent one-off payments. The scenarios below are illustrative: the payment types and the reasons that apply are agreed with each organization.
A payment is closed when every state has a confirmation behind it: the instruction approved, the order booked, the execution confirmed by the channel and the movement matched to the document behind it. A rejection or a return sends the payment back through the route before it gets there. The practical way in is one payment type, followed through to reconciliation.
Corporate Payments and Reconciliation is an EAFlow cross-industry solution on the Operational Graph, with the BPMflow automation capabilities behind the case work. It coordinates the route and records the confirmation for each state; the decision to disburse, the execution of the payment and the banking infrastructure remain with the organization and its banks. Approval bands, rejection reasons and confirming sources are configured with each organization.
