How to implement segregation of duties in your AP controls

Segregation of duties tends to look clean on paper. One person creates the payment. Someone else reviews it. A manager approves it. A separate authorised user releases the funds. Accounting reconciles the result.

That model works — until international payment operations add extra entities, extra currencies, extra approval rights, and extra system access to manage. The risk is no longer just whether a supplier payment looks legitimate. It's whether one person can push too much of the payment lifecycle forward without another control point stopping them.

For finance teams managing cross-border payments, the SoD question becomes more precise.

• Who can create a payment from which entity?
• Who can edit beneficiary data?
• Who can approve FX conversion and payment value?
• Who can release funds?
• Who can reconcile the transaction after settlement?

That's the governance layer this article will cover.

We’ll explore how segregation of duties works within accounts payable for international payments, where domestic AP controls tend to strain, and how finance teams can reduce internal error, credential misuse, rushed approvals, and payment release risk.

What does segregation of duties mean for international payment teams?

Segregation of duties means no single person controls an entire payment lifecycle. The principle is familiar. Applying it to international financial operations means mapping authority across entities, currencies, approval limits, and payment release rights.

A common SoD model splits financial transactions across four functions:

• Authorisation: The right to approve a payment for execution
• Custody: Control over the ability to release payments, access funds, or change payment permissions
• Recordkeeping: Capturing the transaction in the books, with supporting documentation
• Reconciliation: Matching internal records against payment status, account movements, and bank statements

That said, this isn't the only option. Some teams separate payment release from authorisation. Some treat beneficiary data maintenance as its own restricted role. The exact matrix can vary, but the control logic stays the same.

International payments make each function more sensitive.

Authorisation has to account for entity-level authority. A user approved for the French entity may not have authority to approve a payment from the German subsidiary, even if the supplier and amount look familiar.

Custody shifts from physical asset handling to platform rights. The important question is who can release funds, edit user permissions, change payment limits, or modify payment details before money leaves the account.

Recordkeeping has to capture the entity, currency, exchange rate, approval path, supporting invoice, and payment reference.

Reconciliation has to account for FX conversion, settlement timing, payment status, and the final amount received.

Access control in this context has to cover the approver, the entity, the currency, the amount threshold, and the payment action they can touch. Financial controls built for one entity become financial integrity risks when the same permissions quietly stretch across several.

How to apply segregation of duties accounts payable controls to international payments

The six controls below focus on the internal governance layer of international supplier payments. They're less about spotting a suspicious email and more about making sure one user can't create, approve, and release a payment without the right checks around them.

1. Separate the approval process from payment execution

The person who creates an international payment shouldn't be able to approve and release it alone as well. That's the foundation.

The payment approval process needs to separate three moments that often get blurred in busy AP teams:

• Creating or importing the payment
• Approving the payment value, entity, currency, and supporting documentation
• Releasing the payment for execution

Each step carries a different risk. Creation risk is usually data quality and duplicate invoices, approval risk is judgment under time pressure, and release risk is custody over company funds.

Payment authorisations also tend to work better when they're tiered by value threshold, entity, and currency-equivalent amount. One approver may be enough below a low threshold, but dual approval may be required above it. And senior-level finance sign-off may be reserved for higher-value transfers or sensitive entities.

Those thresholds need to work across a multi-entity approval workflow and across currency-equivalent values.

The end goal is simple:

A payment moves forward once the right person has performed the right action at the right point in the lifecycle.

2. Build approval workflows that cross borders and currencies

Domestic approval workflows often assume one entity, one currency, and one finance team. Cross-border workflows tend to need more routing logic.

A payment from your French entity in EUR shouldn't necessarily follow the same path as a USD payment from your UK entity or a GBP payment from a shared services team. The corridor may matter. The entity matters. The currency exposure may matter. The user's authority level definitely matters.

Approval workflows should route invoice approvals based on the control variables that actually affect payment risk:

• Entity making the payment
• Payment amount in local and base currency
• Currency pair and FX conversion step
• Payment corridor or beneficiary country
• User role, approval limit, and release authority
  

Automating cross-border payment routing removes the judgment call from the person creating the payment. The workflow sends it to the right reviewer based on pre-set rules.

Scheduled payments can still fit this model. Recurring supplier invoices in stable corridors may carry standing approval up to a defined threshold, with fresh approval required when the amount, entity, currency, or beneficiary record changes.

The workflow becomes the control. It keeps routine electronic fund transfer activity moving without letting convenience turn into unchecked release authority.

3. Restrict data entry controls and beneficiary maintenance rights

Data entry controls are critical for one core reason:

They decide who can change the payment record before approval and release.

Supplier verification steps belong in a separate workflow. Segregation of duties looks at the internal permission model around payment changes. The same user shouldn't be able to create a supplier, edit beneficiary data, approve the invoice payment, and release funds without another role reviewing the change.

For international AP, restricted data entry controls should cover:

• New beneficiary creation
• Bank account or IBAN edits
• Beneficiary name changes
• Currency or payment-country changes
• Duplicate invoices and duplicate payments
• Manual edits after invoice processing

Optical character recognition in invoice processing can flag duplicate invoices and duplicate payments before they reach approval. That helps with payment accuracy, but it doesn't replace role separation.

If you're working with iBanFirst, our Verification of Beneficiary (VoB) system can check account-name alignment before execution on eligible payments. In a segregation-of-duties framework, that check is one layer inside a broader control design. The governance question is still who can override, approve, or release when a mismatch appears.

That's where many AP processes get thin — they add a verification step, but the same person still has too much permission around the payment record.

4. Treat audit trails and real-time tracking as governance evidence

Audit trails are after-the-fact records for auditors, but in international payments, they also prove that the right roles acted in the right order.

A useful audit trail should show:

• Who created the payment
• Who changed payment or beneficiary data
• Who reviewed the supporting invoice
• Who approved the payment
• Who released the funds
• Which entity, currency, amount, and rate applied
• What happened to the payment after release

Real-time SWIFT payment tracking with timestamped status updates turns payment movement into an auditable sequence. That matters because the control process doesn't simply end when someone clicks "release" on a payment.

Finance still needs to confirm whether the payment was initiated, processed, settled, returned, or delayed. Without that visibility, reconciliation teams may work from partial records and payment teams may send follow-up instructions based on guesswork.

Internally, audit trails support financial reporting, financial statements, and accurate financial records. Externally, shareable tracking links can give suppliers visibility without forcing AP teams into repeated status emails.

Real-time tracking turns operational visibility into governance evidence.

That evidence feeds payment reconciliation across currencies and entities. It also helps finance leaders answer a question auditors often care about.

Who did what, when, and under whose authority?

5. Staff your accounts payable department for multi-entity SoD

Many mid-market finance teams don't have one AP team per entity. The same accounts payable department may support several subsidiaries, currencies, and payment workflows.

That's normal. It just makes role design more important.

The fix is usually cleaner role-based access, not necessarily more headcount. A person can create payments for one entity, approve payments for another, and reconcile a third, as long as the same person can't control the full lifecycle for the same payment.

Compensating controls for small teams can keep accounts payable controls intact:

• Dual approval above defined thresholds
• Job rotation across entity responsibilities
• Periodic review of user permissions
• Separate release rights for high-value payments
• Manager review of permission changes
• Clear backup roles for holidays and absences

This is where a documented finance department structure helps. It maps role separation across procure-to-pay, treasury, and accounting so the team can see where authority overlaps.

The danger is rarely one obvious super-user. It's the quiet accumulation of rights over time as people cover holidays, take on new entities, or keep legacy access after a role change.

6. Choose a cross-border payment platform built for international operations

Choosing a cross-border payment platform is a control architecture decision more than a software decision. The platform either encodes your SoD matrix into payment processes or leaves finance to police the matrix manually.

A purpose-built cross-border platform like iBanFirst can support multi-signature approvals, granular user permissions, beneficiary checks, and real-time tracking inside the same electronic payments infrastructure. That matters because controls tend to work better when they live where the payment is created, approved, released, and tracked.

Stitching together domestic bank accounts, manual FX tools, spreadsheet approvals, and disconnected AP software often creates gaps between policy and execution.

When the platform is the control layer, the SoD matrix doesn't depend on people remembering the rules under time pressure. The system can restrict what each user is allowed to do before funds leave.

Where domestic accounts payable internal controls break down

Domestic accounts payable internal controls usually assume a smaller control surface. International payments stretch that surface across entities, currencies, permission sets, and approval rights.

Fraud risks that intensify in cross-border payments

Business email compromise and external fraud sit outside the main focus of this article. They still matter to SoD because compromised credentials can turn a weak permission model into a payment release event.

BEC accounted for US$2.8 billion in losses in 2024, according to the FBI IC3 2024 Annual Report. Cross-border misdirected payments can be especially hard to recover — with recovery rates often under 5%, according to iPiD, a payments intelligence platform.

The SoD lesson is that payment fraud prevention also depends on internal authority design, not another layer of fraud checklists.

If a compromised user account can create a payment, approve it, and release it, the control framework has already failed. If the same account has creation rights but a separate authorised role must approve and release it, the attacker has more to overcome.

That's the difference between awareness and enforceable payment controls.

Regulatory divergence across jurisdictions

A payment approved in France under PSD2 requirements may face different evidence expectations than a payment received in the UK under FCA EMI regulation or reviewed under FATF AML guidance.

The goal is to make the approval chain transparent enough that finance can show which authorised user approved which payment, for which entity, in which currency, under which internal policy.

Businesses operating across jurisdictions often face a specific SoD problem. The person approving the payment may not know which regulatory requirements apply downstream.

Encoding jurisdiction and entity context into the workflow helps ensure regulatory compliance at execution time rather than leaving gaps for audit.

Control failures in the AP process without real-time visibility

A payment can be properly approved and still create a control issue after release.

If AP can't see whether a payment is initiated, pending, settled, returned, or delayed, the team can't reconcile confidently. That uncertainty can trigger duplicate payment attempts, supplier escalations, manual status chasing, and cash flow management guesswork.

Those are control failures in the AP process, as well as service issues.

Payment status visibility helps finance confirm that timely payments actually moved as expected. It also gives reconciliation teams a clean record of what happened after release, rather than forcing them to rebuild the timeline from emails, bank statements, and supplier messages.

What finance teams often get wrong about internal controls for international payments

Two assumptions create much of the trouble. They're both understandable. They both leave finance teams with controls that look stronger in policy than they are in practice.

Treating SoD as a domestic framework with an international add-on

A common mistake is taking the domestic SoD framework and adding international payments as an exception workflow.

That feels efficient because the core duties look familiar. Someone creates, someone approves, someone reconciles.

But international payments add authority questions the domestic matrix may not answer. Which entity can the user act for? Which currency can they approve? Who can accept the FX rate? Who can release funds from each account? Who reviews permission changes?

Strong internal controls for international payments work better when entity, currency, payment value, and release authority are primary control dimensions from the start.

That's also the kind of foundation you need when you manage finances across several subsidiaries. The control matrix has to match the business structure beyond the home office approval chart.

Running manual processes across multiple entities

What happens when your AP team processes invoice payments for three entities using spreadsheets and email approvals?

Manual touchpoints create places where a control can fail. Purchase orders approved in email threads lack clean audit trails. Payment files exported from one accounts payable system and uploaded to another AP system create reconciliation gaps that compound as volume grows.

The problem grows with entity count. Each additional entity adds another set of approval limits, payment rights, user permissions, and accounting records to maintain.

Manual processes can work at low volume, but they tend to drift as the payment workload grows. SoD depends on consistency, and consistency is hard to maintain when the control sits outside the system where payment decisions happen.

How to build internal controls that hold across borders

Cross-border internal controls need three layers working together. Policy defines the rule. Process turns the rule into a workflow. Platform permissions enforce the workflow before money moves.

The layers are:

• Policy layer: Define which roles hold which authority across each entity. Map approval limits by entity, currency, and payment type. Document who can create, review, approve, release, reconcile, and change permissions
• Process layer: Design accounts payable processes around the real risk points. Approval routing should account for entity, currency, value threshold, FX decision, and release authority. Accounting processes for reconciliation need the same payment references and status data that payment teams use
• Platform layer: Put the rules into the system. The platform should govern who can approve, for which entity, up to what amount, in which currencies, and whether the same user can release the payment afterwards

Policy without process is theory. Process without platform enforcement is manual compliance.

Financial accuracy in multi-currency environments depends on the controls framework capturing conversion rates, payment status, and settlement timing. The final amount recorded in the ledger has to match. That’s difficult to do if approvals happen in email and execution happens somewhere else. 

How the right software enforces segregation of duties at scale

Software doesn't replace SoD — it makes SoD enforceable.

Manual processes rely on people following rules. The right finance and automation software can enforce those rules at the system level so the AP system refuses non-compliant actions before they become payment events.

Five capability categories matter for cross-border SoD enforcement:

• Automation: Workflow automation routes payments through the correct approval path based on entity, value, currency, and user role
• Custom user roles: Role-based access restricts what each user can create, edit, approve, release, and reconcile
• Multi-step approval processes: Electronic payments move through layered approval tiers before funds can leave the account
• Full audit trails: Sensitive actions create timestamped, user-attributed records that link payment approval, release, tracking, and ledger records
• Pre-built accounting and ERP integrations: The payment platform connects approval data, payment records, and reconciliation outputs to the accounting system without manual re-entry

What does this change operationally?

It converts SoD from a policy that people follow into a system constraint that's much harder to bypass. The platform becomes the control layer.

As entity count, payment volume, and corridor diversity grow, manual SoD enforcement tends to degrade. Software-enforced controls hold because permissions, thresholds, and release rights are applied consistently.

System-enforced SoD generates an audit trail that doubles as your AP audit readiness tool. When auditors ask who approved a payment, the answer is in the system, not buried in an email thread.

How iBanFirst helps finance teams enforce accounts payable controls across borders

Segregation of duties across international financial operations doesn't have to mean shared payment logins, unclear approval rights, rushed release decisions, and reconciliation records that have to be rebuilt after the fact.

That’s where iBanFirst comes in.

iBanFirst is a European cross-border payment provider built for established SMEs managing significant cross-border payment volumes — finance teams running cross-border financial transactions across multiple entities, currencies, and jurisdictions where SoD enforcement is operational infrastructure.

With iBanFirst, you can:

• Control who can create, approve, and release international supplier payments with multi-signature approvals and granular user permissions across entities
• Restrict payment rights by role, entity, approval threshold, and release authority so one user can't move a payment through the full lifecycle alone
• Check beneficiary details before execution through Verification of Beneficiary when eligible, keeping account validation inside the controlled payment workflow
• Track eligible SWIFT payments live after approval through completion, with timestamped updates and shareable tracking links that support audit evidence
• Manage cross-border payments to 180+ countries from a single multi-currency account, with 25 currencies available and transparent FX spreads displayed before execution

Request an account to see how iBanFirst helps control who can create, approve, release, and track international supplier payments. 

Common questions about segregation of duties

What are the fraud risks of weak AP internal controls?

The primary fraud threats from weak AP internal controls are unauthorised payments, duplicate payments, credential misuse, and business email compromise.

For international finance teams, the financial risk compounds when one user can create, approve, and release a payment without independent review. Multi-signature approval controls, granular permissions, beneficiary checks, and payment tracking reduce that risk by forcing sensitive payment actions through separate roles.

How does fraud prevention work in international payment workflows?

Payment fraud prevention in international workflows works through layered payment controls:

• Beneficiary checks help confirm payment details before execution
• Multi-level approval routing sends payments through the right sign-off chain based on amount, currency, entity, and user authority
• Real-time tracking makes payment status visible after release so anomalies can surface before the finance team loses the thread

What is the difference between the approval process and payment authorisation?

The payment approval process is the workflow that routes a payment request through review. Payment authorisation is the sign-off that allows funds to be released.

In international operations, the approval process may involve reviewers across entities and jurisdictions. Authorisation authority is usually tied to a specific entity, threshold, and role. Role-based permissions enforce that separation so the person who creates a payment can't also release it without the required approval path.