04 / The handoff outside your ERP
Can you pay manually while an ERP payment is pending?
A bank-portal payment is a separate release. Before using it for the same obligation, establish whether the original payment can still complete. Keep the proposed replacement on hold while that remains unresolved, then review the exact payment under current authority.
Who can still release money outside the ERP?
Follow the evidenceOne invoice. Two teams. Two ways to pay.
In this fictional example, AP submits a USD 10,000 supplier payment through its ERP. The status remains pending. To meet a deadline, Treasury is asked to send the same amount through the bank portal.
ERP payment
AP has submitted the instruction. The team has not established whether it paid or may pay later.
Bank-portal payment
Treasury can prepare a separate instruction. Its approver needs the original attempt's evidence before release.
No duplicate payment has been established. The question is whether another full payment could create one.
Moving the task to another team does not resolve the earlier attempt. A portal approval can authorize an instruction without establishing that the ERP payment cannot also complete.
Provider-supported retries are a different operation. Stripe and Adyen document protected same-request retries within their applicable contracts.12 For that distinction, read when a payment retry is safe after a timeout.
Make the handoff explicit.
Assign these responsibilities in your own procedure. One person may cover several tasks where policy permits; required approval separation still applies.
| Responsibility | Establish | Retain |
|---|---|---|
| AP / obligation owner | Which obligation, supplier, amount and currency both instructions concern. | Invoice and attempt references, submission time and the last known state. |
| Treasury / portal preparer | The exact proposed destination, amount, account and release path. | A linked proposal and its preparation status. Confirm whether saving or uploading can itself schedule payment. |
| Bank or provider liaison | The original operation's authoritative status and any remaining ability to execute. | Matched records and route-specific status semantics. A cancellation request alone is not proof of cancellation. |
| Workflow / system owner | Whether a queue, retry job, uploaded file or other actor can still release the original or another replacement. | Evidence of the applicable pause or exclusion and who controls it. |
| Authorized release approver | Current authority for this exact proposal, using the matched outcome and other active attempts. | The decision, reviewer, time, evidence references and remaining uncertainty. |
Close the original. Recheck the replacement.
- Link both instructions. Confirm the same underlying obligation even if the ERP, portal and bank use different references. Account for previous partial payments separately.
- Resolve the original outcome. If it paid in full, another full payment is not eligible under this model. If it remains unresolved, retain the hold on the proposed replacement.
- Check what can still execute. A local “failed” label, a requested recall or the absence of a statement entry may not close delayed execution. Use the bank or provider's applicable procedure and evidence.
- Review current authority. If the original did not pay and cannot pay later, check the replacement's beneficiary, amount, currency, approvals and remaining capacity again. Closure alone does not approve it.
- Coordinate the release. Establish how another preparer, queue or route is prevented from releasing a competing replacement between review and dispatch. If that exclusion is unverified, coverage remains unverified.
- Link the final record. Reconcile the released instruction back to the obligation and retain its outcome. A later bookkeeping entry cannot undo an already duplicated payment.
Use the coverage worksheet to record the paths, owners and missing evidence. For the explanatory lifecycle, open the synthetic demo.
A deadline changes the escalation.
Record the deadline, supplier impact, accountable decision owner and next review time. Escalate through the organization's approved exception procedure and the relevant bank or provider contact.
KEEP THE UNCERTAINTY VISIBLE
Urgent approval does not establish the original outcome. If a policy permits an exception, document the unresolved exposure and its owner. Do not describe the replacement as duplicate-safe on the strength of that approval alone.
Also check the handoff at shift change. The next operator needs the active attempts and evidence, not only an instruction to “pay manually.”
Inspect the basis
Put this question to the evidence.
- R25 · A manual path bypasses the hold
All four models fail this recorded bypass case. A local hold does not establish coverage.
- Map the handoff
Use the fictional worksheet to assign each path an owner and an evidence check.
Recorded synthetic examples. These findings do not establish the behavior of your workflow.
Sources and limits
- Stripe: Advanced error handling. Provider-specific handling of network errors, indeterminate outcomes and retries.
- Adyen: API idempotency. Provider-specific retry scope and error handling.
- HALTSEAL's public control model. Obligation, uncertainty, fresh authority and coverage.
External documentation reviewed September 28, 2026. The handoff and checklist are HALTSEAL's proposed review framework, not those providers' bank-portal instructions. This fictional full-payment example is not a customer incident or native ERP/bank integration. Partial payments, returns, recalls and changed obligations require their own accounting and route-specific rules. No manual path is automatically covered by HALTSEAL; the published evidence and integration limits remain applicable.