How to Automate Corporate Payments Across Accounts and Entities

Map Your Entities, Accounts and Payment Workflows

Multi-entity payment automation starts with an accurate map of who owes each liability and which accounts may fund it. A central dashboard can simplify operations, but it must preserve legal-entity boundaries. Record the entity owing the liability separately from any entity executing or funding the payment under an authorised payment-on-behalf-of arrangement. For invoices, identify the receiving company, contracting company and funding account.

Define which payment types are in scope. This workflow focuses on supplier invoices; payroll and tax payments require separate source records, approvals and payment references.

Create an inventory that finance and treasury teams can validate:

• Entities: Legal names, registration identifiers, jurisdictions, business units and responsible finance owners.
• Accounts: Account holder, bank or payment provider, currency, purpose, authorised users and permitted payment methods.
• Workload: Monthly and peak payment counts, typical and maximum values, supplier locations and payment deadlines.
• Systems: ERP, accounting, procurement, supplier-master, treasury and bank-portal systems, including who owns each record.
• Existing instructions: Standing orders, Direct Debits and scheduled bank payments, with a decision to retain, amend or cancel each during migration to prevent duplicates.

Next, trace a representative invoice from receipt to reconciliation. Record where it is coded, checked, approved, selected for payment, submitted and matched to a bank movement. Include manual steps such as emailing approval, exporting a spreadsheet or re-entering bank details. Each handoff should have a named owner and a defined input and output.

Supplier data often needs attention before automation. The same supplier may appear under different names in several systems, while one record may contain obsolete bank details. Distinguish genuine duplicates from separate legal suppliers, and document which system is authoritative. Bank-detail changes should follow an independently verified process rather than being accepted solely because an email or invoice contains new instructions.

Centralisation can cover preparation, scheduling, reporting and shared operational support. Approval mandates, accounting entries, account ownership and funding restrictions may need to remain entity-specific. Paying a subsidiary's invoice from another group entity's account can create intercompany balances and legal or tax questions; do not assume that group membership alone permits unrestricted funding.

For example, a shared finance team can prepare one payment run containing obligations from two subsidiaries while releasing separate instructions from each subsidiary's authorised account. The consolidated view improves coordination without merging the liabilities.

The output of this exercise is a controlled process map and data inventory, with unresolved ownership questions made visible. It provides the requirements for selecting and connecting a payment system instead of carrying existing ambiguities into the automated workflow.

Select and Connect a B2B Payment System

Select the system against the entity and account map created in the previous step. It must support the legal entities, funding accounts, currencies, payment volumes and finance systems in scope. A central dashboard is useful only if every payment remains attributable to the correct company, account, supplier and underlying liability.

Identify the actual payment service provider behind the software, verify its relevant FCA status and permissions, and establish who holds customer funds. Safeguarding at a payment or e-money institution is different from FSCS protection for eligible bank deposits; confirm which protections apply to the proposed arrangement.

Choose the simplest connection that supports the required workflow. A secure file import can be appropriate for scheduled payment runs. An ERP connector can reduce rekeying where its supported records match your configuration. An API can support event-driven payouts and detailed status updates, but it also requires engineering ownership, monitoring and safe recovery from timeouts. These methods can coexist for different entities or payment types.

Define a canonical payment record before integration. At minimum, include the paying legal entity, source account, supplier identifier, approved liability, currency, amount, requested date and a unique instruction reference. Preserve the external provider reference and final bank reference when available. Do not use supplier name or amount alone to identify a payment, because repeated invoices and similar payments are common.

Connect a test environment first and exercise the complete lifecycle. Import or create an approved invoice, generate a payment instruction, receive each status and reconcile the final debit. Test a duplicate request, lost response, rejected beneficiary and partial batch failure. A retry after an uncertain outcome should retrieve or safely repeat the same operation without paying twice. Authenticate incoming status notifications, prevent duplicate processing, handle out-of-order messages without reverting to an older status, and recover missed updates through provider queries or replay.

Confirm how credentials are separated by environment and entity. Restrict the integration to the accounts and actions it needs, rotate secrets under a documented process and monitor failed authentication. Assign ownership for connector upgrades, expired certificates, data-mapping changes and reconciliation breaks.

Before production approval, compare the provider's transaction and fee exports with the fields required by finance. Reconcile a complete test period, including opening and closing balances, rather than checking only successful payments. The connection is ready when the business can trace each approved liability through execution and accounting without relying on manual reconstruction.

Configure Entity-Level Approvals and Fraud Controls

Apply approval rules to the legal entity that owns the liability and the account that will fund it. A group-wide payment interface should not allow a user authorised for one subsidiary to release funds from another. Define roles, limits and escalation paths before users are added, then test the rules with representative payments.

Use individual accounts and strong authentication for human users. Do not share credentials between finance staff or entities. Service accounts need narrowly scoped permissions, protected credentials and monitoring appropriate to their functions. Remove access promptly when responsibilities change, and review privileged roles on a defined schedule.

Supplier bank-detail fraud often begins with a convincing request to change payment instructions. Require staff to verify a new or amended account through a trusted channel using contact details already held, rather than the email or telephone number in the change request. The NCSC's business payment fraud guidance describes how impersonation can redirect payments. Confirmation of Payee can support account-name checking where available, but it does not prove that an invoice or change request is genuine.

Define an action for each Confirmation of Payee result. A match can proceed through the remaining controls; a close match requires checking and, where appropriate, correcting the name and rerunning the check. Pause no-match or unavailable results for independent verification. Permit an override only under a documented policy with authorised approval and retained evidence.

Assign responsibility for sanctions checks, including relevant ownership and control checks: an unlisted entity may still be restricted through a designated owner or controller. Hold potential matches for review and escalate to the designated compliance owner before release.

Configure rules that identify unusual activity without making the alert volume unmanageable. Relevant signals can include a first payment to a beneficiary, a changed account, an unexpected country, a payment outside the normal schedule, rapid repeated submissions or an amount inconsistent with prior activity. Define who reviews an alert, what evidence is required and when the payment must be stopped or escalated.

If fraud is suspected, stop pending instructions where possible, contact the bank immediately using verified details, notify internal IT or security and preserve payment records, messages and audit logs.

Protect the approved payment after review. If the amount, recipient, source account or requested execution date changes, invalidate the earlier approval and require the revised instruction to pass through the appropriate workflow. File replacement and API retries must not bypass this rule.

Test permissions with both permitted and prohibited actions. Confirm that users cannot approve their own restricted payments, view unrelated entities or lower control settings without authorisation. Export the audit trail and verify that it records changes to users, beneficiaries, limits and payments. A control is effective only when it prevents unauthorised action and leaves evidence that finance and auditors can examine.

Automate Cash Visibility and Funding Checks

Centralise cash information without obscuring which legal entity owns each balance. A group dashboard can aggregate data for treasury decisions, but every account, liability and transfer must remain mapped to the correct entity and currency. Define whether each figure is a bank-booked balance, an available balance, an internal ledger balance or a forecast before using it to approve payments.

Calculate a funding position for each entity, account, currency and execution date. Start with available funds, subtract committed outflows not already reflected in that balance, and deduct the required liquidity buffer. Include expected payment fees and FX funding requirements once, without double-counting payments, holds or reservations. Treat expected receipts separately until the policy permits reliance on them. A positive group total does not cure a shortfall in the paying entity if funds cannot lawfully or operationally be moved between companies.

Use a shared reservation record for each funding account, with the funds check and reservation performed as one controlled operation so simultaneous runs cannot commit the same funds. Update reservations as payments settle or cancellations are confirmed, ensuring each commitment is counted only once as it becomes reflected in the bank balance.

Automate balance collection at a frequency appropriate to the payment schedule and label the observation time. Detect stale or incomplete feeds instead of carrying forward an old balance as if it were current. If several systems report the same account, identify one authoritative source for payment release and reconcile differences rather than selecting the most favourable figure.

Create alerts for forecast shortfalls, unusual balance changes, missed receipts and payments approaching their cut-off without sufficient funds. Route each alert to a named owner with a deadline. The workflow should distinguish a genuine shortage from a delayed feed, duplicate commitment or payment already cancelled elsewhere. If a funding check fails, hold the affected payments and request an approved funding transfer, prioritise obligations or reschedule under treasury policy. Rerun the check before release.

Where intercompany funding is permitted, record the legal entity providing funds, the recipient, currency, amount, purpose and appropriate accounting treatment. Do not allow the automation layer to sweep or net balances across entities merely because they appear in one dashboard. Treasury policies, agreements, tax considerations and account mandates may require separate approval.

Test the check with pending transactions and timing differences. For example, a GBP 100,000 available balance that does not yet reflect GBP 35,000 of approved payments leaves GBP 45,000 for further commitments after a GBP 20,000 buffer, assuming no additional fees or FX funding requirements. A GBP 50,000 receipt expected tomorrow cannot fund a payment due today; any bridging funds must be separately available and approved.

Retain the balance snapshot and rule result used for each payment run. After execution, compare forecast debits with bank and provider records. Accurate cash visibility means finance can explain both the amount displayed and the commitments that reduce it.

Schedule, Route and Execute Payments

Schedule payments from the contractual due date and the selected route's processing cycle. The system should calculate when an instruction must be approved and funded, allowing for provider cut-offs, weekends, bank holidays and time zones. A requested date is not complete unless it states whether it means submission, settlement or expected beneficiary credit.

Official scheme information provides the starting point: Bacs describes its three-day processing cycle, Pay.UK explains how Faster Payments work, and the Bank of England describes CHAPS. The service offered to your business can have earlier cut-offs or lower limits, so configure contracted conditions rather than scheme maxima alone.

Route a payment according to documented rules covering currency, destination, value, urgency, cost and recipient capability. If more than one route qualifies, record why the system selected one. Require approval when a user overrides the normal route, changes the execution date or accepts a materially different FX outcome.

Lock the approved payment content before execution. Assign a stable instruction ID and an idempotency key or equivalent duplicate-control reference. If a submission times out, query the existing operation before resending. A technical failure to receive a response does not prove that the payment failed.

Track each instruction individually, even when payments are submitted as a batch. Use explicit states such as prepared, approved, scheduled, submitted, accepted, completed, rejected, returned and cancelled. Map provider statuses to these states by route, documenting whether “completed” confirms execution, interbank settlement or beneficiary credit. Where beneficiary-credit confirmation is unavailable, record that limitation rather than implying receipt. Do not mark a supplier invoice as settled merely because the batch was accepted; one item may fail while others succeed.

Distinguish cancellation of a pending instruction from a recall request after submission and recovery of funds already paid. Availability and deadlines depend on the route and provider: Faster Payments cannot be cancelled once sent, and CHAPS settlement is irrevocable between direct participants. A recall or recovery request does not guarantee that funds will be returned.

Before release, rerun the relevant account, currency, limit and approval checks. During execution, monitor stopped jobs, stale scheduled items and unexpected provider responses. After submission, capture the provider reference, fees, FX details and timestamps needed for reconciliation.

Send automated supplier remittance advice at a defined, verified execution milestone, including invoice allocations, amounts and payment references. Describe the confirmed status accurately, avoid implying beneficiary receipt without evidence, and issue an update if the payment is subsequently returned.

Maintain a controlled fallback for provider outages or missed cut-offs. It should identify payments already submitted before staff use another bank or channel, preventing duplicate settlement. Escalate critical supplier, payroll or tax payments early enough to use the approved alternative route.

Reconcile Payments and Resolve Exceptions

Reconcile at transaction level and at the level of each funding account. The objective is to connect the approved liability, payment instruction, provider outcome, bank movement and accounting entry. A matching batch total is insufficient because a missing payment and an unrelated duplicate can cancel each other numerically.

1. Confirm source completeness: Check that all expected bank statements, provider reports, API pages and status messages were received for the reconciliation period.
2. Match stable references: Use the internal instruction ID, provider transaction ID, bank reference, entity, account, currency and amount. Do not rely on amount and date alone when several payments can look alike.
3. Allocate payments: Link partial payments to the original invoice and retain the outstanding balance. Allocate payments covering several invoices and any credit notes explicitly, and break aggregated bank debits into their underlying transactions.
4. Explain the settlement bridge: Separate payment principal, provider fees, FX differences, returned funds and other adjustments so finance can reproduce the account movement.
5. Reconcile control totals: Verify opening balance plus receipts and other credits, less payments, fees and other debits, equals the closing balance for each account and currency.
6. Post confirmed outcomes: Update the accounting system according to documented status rules and retain the external evidence supporting the entry.

For payments made on behalf of another entity, also reconcile the corresponding intercompany receivable and payable and any clearing accounts, linking both entities' entries to the supplier liability and bank movement.

Classify exceptions so they reach the right owner. A rejected payment may require corrected beneficiary details; an accepted payment with an unknown final outcome requires provider investigation. For a returned payment, record the return, reverse or adjust the settlement entry and reopen the original payable where appropriate, then approve any replacement instruction. The return does not itself create a new underlying liability. Missing reports, duplicate postings, incorrect entity mappings and unexplained fees are separate control failures even when the supplier was eventually paid.

Set reconciliation frequency according to volume and risk, with a defined period-end review. Carry payments in transit as supported reconciling items under the accounting policy and verify their subsequent settlement. Document authorised matching and write-off tolerances, and require independent review and sign-off of unresolved exceptions without treating sign-off as resolution.

Give every open exception an amount, currency, entity, owner, age and next action. Prioritise by payment deadline, customer or supplier impact, value and financial-reporting risk. A suspense account may temporarily classify a known movement, but it does not resolve the underlying exception.

Preserve the original transaction history. Correct financial records through linked reversals or adjustments under the accounting policy instead of overwriting posted entries. After correction, rerun the affected reconciliation and confirm that downstream reports agree. Retain supporting records and audit trails under applicable retention requirements, with controlled access and retrieval by entity, period and transaction reference.

Track aged unmatched value, exception rate, time to resolution and recurring root causes. Use the findings to improve supplier data, routing rules, integration monitoring and approval controls. Reconciliation is complete when the account movement and every material exception are explainable, not merely when the dashboard displays a green status.

Pilot the Workflow and Measure Results

Start with a limited but representative pilot rather than moving every entity and account at once. Select one or two entities with known payment volumes, clean supplier records and an approved fallback process. Include the payment types that drive the business case, while placing explicit limits on users, currencies, transaction values and total exposure.

Record a baseline before the pilot. Measure preparation, approval and reconciliation time; payment and FX charges; rejected or returned payments; manual corrections; late payments; and support effort. Use the same definitions during and after the pilot so the result is comparable.

Define each measurement cohort, observation window and reporting cut-off. Count retries against the original payment rather than as new obligations, report pending and returned payments separately, and carry period-end items forward consistently. Use the same cohort for each rate's numerator and denominator, with exclusions documented.

1. Agree acceptance criteria: Set required completion rates, timing, reconciliation coverage, control results and cost outcomes before processing live payments. Name the owners authorised to approve rollout or trigger rollback.
2. Validate readiness: Confirm entity mappings, funding accounts, user permissions, beneficiary data, reporting feeds, support contacts and incident procedures. Require completed user training and an accepted operational handover.
3. Test failure paths: Exercise a duplicate submission, rejected beneficiary, missing response, delayed status, insufficient funds and unavailable provider connection.
4. Process a controlled live run: Reconcile every instruction and independently confirm a sample of expected recipient outcomes.
5. Review and expand: Correct root causes and obtain the designated owner's approval before adding entities, accounts, payment routes or higher limits.

Review results by entity, payment route, currency and exception type. An improved group average can conceal a failed subsidiary workflow or an expensive international corridor. Compare actual invoices and staff time with the assumptions in the business case, and distinguish capacity released from cash expenditure that was genuinely avoided. Assess payback over a stated evaluation period, including implementation, integration, migration and training costs alongside recurring subscriptions, transaction charges, FX costs and support.

Set stop conditions. Pause expansion for unexplained account differences, uncontrolled duplicate-payment risk, missing approval evidence or a failure to recover from an outage. The designated owner should decide whether to remediate, pause live processing or invoke rollback. The fallback process must check whether instructions were already executed before staff submit them through another channel.

After acceptance, move additional entities in manageable waves and reconcile each cutover period. Retain the legacy records and access needed for audit and investigation. Continue monitoring service levels, permissions, costs and exceptions after rollout; a successful pilot proves initial suitability, while ongoing measurement shows whether the automation continues to deliver control and financial value.