SiGMA World 2026 Rome — Meet EQWIRE at booth H8-6058
SiGMA World 2026 Rome — Meet EQWIRE at booth H8-6058

•

•

UK Multi-Currency Account for a Corporate Invoicing Provider with PSP Settlements

UK Multi-Currency Account for a Corporate Invoicing Provider with PSP Settlements

Content

Share

PSP Settlement Reconciliation for Invoicing Providers

Articles

UK Multi-Currency Account for a Corporate Invoicing Provider with PSP Settlements

[aa disclaimer]
Legal Disclaimer: This article is for informational purposes only and does not constitute legal, financial, compliance, or tax advice. Banking eligibility and regulatory requirements vary by jurisdiction, as do provider policies. Consult qualified professionals before making decisions.
[/aa]

A €14,490 deposit can contain payments against dozens of invoices. Its reference may identify only a processor batch. Finance staff must then identify the paid invoices and explain any deductions from the underlying customer payments.

A UK multi-currency account for a corporate invoicing provider with PSP settlements needs separate currency records and a traceable link from each invoice to the incoming payout. The receiving account supplies evidence of cash arrival. Allocation depends on billing data and transaction evidence from the payment service provider (PSP).

The practical task is to connect four records: the invoice, the customer payment, the payout batch and the statement entry. Finance teams also need to distinguish their own service revenue from funds belonging to client businesses. This guide sets out a matching workflow with a worked settlement calculation. It also defines controls for clearing exceptions.

[aa key-takeaways]

Key Takeaways

  1. Separate the invoicing provider's own revenue from money collected for its clients.

  2. Retain an invoice-to-payment link before several transactions enter one payout batch.

  3. Explain fees and other deductions through a gross-to-net calculation.

  4. Match each account credit in its payout currency before reporting in sterling.

  5. Keep missing references and unexplained differences in an assigned exception queue.

[aa btn]Book a Call[/aa]
[/aa]

Confirm whose money reaches the settlement account

A corporate invoicing provider must establish who owns the money before selecting receiving details. A software company collecting its own subscriptions has a different flow from a platform receiving sales proceeds on behalf of its client businesses.

Separate service revenue from customer collections

For its own revenue, the provider bills business customers for access to its application. The PSP contract and receiving account should identify the appropriate legal entity. Compliance staff can then assess the payment flow described in the account application.

Customer collections need a separate analysis. An invoicing platform may display bills issued by 200 client businesses while those merchants receive their payouts directly. Visibility of those records does not make the software company the owner of the proceeds.

If the proposed model routes merchants' money through an account controlled by the platform, legal responsibilities change. The Financial Conduct Authority's commercial-agent guidance explains that transferring funds between parties can fall within regulated payment services. An exclusion depends on the actual activities and contractual authority.

The onboarding file should therefore state:

  • Which entity issues the underlying customer invoice.

  • Who contracts with the processor and owns the receivable.

  • Where the PSP sends the payout.

  • Whether another business has a claim to the balance.

  • What happens after a refund or dispute.

A generic business account application cannot establish permission for every collection model. Obtain written confirmation that the provider accepts the proposed use.

Currency routing comes after this ownership check. The existing guide to PSP settlement routing covers payout-destination conditions; the operational question here is how each accepted receipt connects to a bill.

Map invoices to PSP payments before matching payouts

Match the customer's payment to the invoice first, then connect that transaction to its payout. Starting from the statement amount loses detail when a processor combines several receipts.

Required reference fields

The billing system needs a permanent invoice ID and an allocation record. This record links the amount paid to the relevant bill. A single transfer can cover two invoices, while instalments can produce several receipts against one document.

A practical data model uses the following fields:

Record

Fields to retain

Matching purpose

Invoice

Legal entity, invoice ID, customer ID, currency, amount due

Identify the receivable

Customer payment

PSP account, transaction ID, merchant reference, amount, currency

Connect collection to allocation

Payout batch

Payout ID, batch reference, settlement currency, component entries

Explain the processor's transfer

Account statement

Receiving account, transaction reference, credit amount, currency, booking date

Prove receipt

Adjustment

Event ID, original transaction, reason, amount, currency

Explain a deduction or reversal

Keep the original identifiers even when the accounting export adds a shorter display reference. Text truncation should not destroy the underlying join between systems.

Stripe supports internal IDs in report metadata, but availability depends on the type of record and report. Check a sample export before requiring a field. Files for connected merchant accounts may expose different columns.

Invoice reconciliation software must preserve detail when one payment covers several bills. Store the applied amount for each invoice in a separate allocation table. For every customer receipt, those entries plus any unapplied remainder should equal the total collected.

Direct bank transfers follow another path. A named IBAN collection workflow can help identify a payer, but a PSP deposit normally represents the processor's batch. The merchant's underlying transaction data supplies the missing customer-level detail.

The Four Records to Match

PSP settlements: GBP, EUR and USD reconciliation

Reconcile each payout in the currency shown by the processor and receiving statement. Do not add unlike denominations.

For automatic payouts, Stripe's payout reconciliation report identifies the transactions within a settlement batch. For manual or instant payouts, reconcile the transferred amount against the PSP’s balance transaction history.

Adyen's Settlement details report includes merchant references and gross/net currency fields. Its payout entries provide a batch-level connection to the statement. An InvoiceDeduction entry may concern the processor's own bill, so that label alone cannot identify a merchant's customer invoice.

Worked EUR payout

The following amounts are illustrative. They describe one hypothetical batch without currency conversion or additional credits.

Component

EUR

Gross customer receipts

15,000

Refunds included in the batch

−300

Processing fees

−150

Newly withheld reserve

−60

Expected account credit

14,490

The accounting record should explain the €510 difference. A reserve is an amount the PSP retains under its terms; its treatment differs from a processing expense.

Assume a €1,000 customer payment fully clears one invoice under the merchant's payment terms. The processor later deducts a €15 fee before remitting cash. Finance records the collection and processing cost separately; the smaller deposit does not create a fresh €15 customer debt.

Refunds require their own document trail. A €300 reversal might relate to a sale from an earlier payout, so it should carry the original transaction reference and relevant credit-note evidence. Allocating that deduction across today's open invoices would misstate customer balances.

Avoid double subtraction. Some exports already provide a net amount per entry, while others require finance staff to calculate the total from gross amounts and separate adjustments. Follow one documented convention for each report format.

[aa fast-fact]
Fast Fact: Illustrative calculation: €15,000 − €300 − €150 − €60 = €14,490. These fictional amounts demonstrate the reconciliation; they do not represent a provider tariff.
[/aa]

From Gross Receipts to Net Payout

[aa cta]

Check receiving details before changing PSP instructions

An invoicing provider can discuss its approved business model and required currency accounts with EQWIRE before moving settlement flows.

[aa btn]Discuss Account Requirements[/aa]
[/aa]

Choose a multi currency account for business reporting

Choose the account structure by the evidence available for each currency. One dashboard can contain several balances or accounts; it does not imply identical receiving details across all denominations.

Business foreign currency account evidence

For every proposed payout currency, obtain the account holder's name and the exact receiving instructions. Then confirm the PSP accepts that account format for the merchant entity. Currency holding alone cannot establish payout compatibility.

Stripe's multi-currency settlement requirements specify a separate supported receiving account matching each configured settlement currency. An account provider's single interface does not override that requirement. USD holding also does not, by itself, establish access to local US receiving details.

A buyer may pay a EUR invoice in USD. Record the USD amount paid and the EUR amount applied to the invoice. Store the provider’s applied rate alongside any conversion charge. Finance should assess settlement against the agreed billing terms; a sterling reporting value cannot establish whether the original EUR receivable has cleared.

Keep later treasury conversions separate from customer settlement. Moving received euros into pounds changes cash holdings and can create an accounting FX difference. It does not alter which invoice the original collection paid.

Request a sample statement with the proposed currency visible. Test whether its reference survives the export into the accounting package. Repeatedly losing payout IDs during import can turn a technically successful setup into daily manual work.

Invoice reconciliation and the multi-currency account

The receiving statement proves that funds reached the account. Invoice IDs come from billing records; the destination provider cannot recreate absent merchant data.

A multi currency business account is therefore one part of the evidence chain. In its business service description, EQWIRE lists denomination-specific balances and accounting exports; an integration still needs the invoicing company's transaction history.

Account selection also involves fund protection. The FCA explains that non-bank payment providers use safeguarding, while FSCS deposit protection does not cover those balances. The arrangement differs from holding a bank deposit and should form part of the account assessment.

Keep Currency Records Separate

Clear exceptions without closing the wrong invoice

A payment reconciliation rule should stop when its supporting identifiers disagree. Matching on an amount and a nearby date is unsafe if several customers owe the same sum.

Build an exception queue

Assign each unresolved item a reason and an owner. Include the amount at risk and next action, with supporting evidence. A review date keeps the record from remaining indefinitely unallocated.

Exception

Investigation

Accounting safeguard

Missing invoice reference

Retrieve merchant metadata or customer remittance

Keep cash unapplied pending evidence

Partial payment

Compare the allocation with the remaining amount due

Leave the unpaid portion open

Refund or dispute

Locate the original collection and adjustment record

Avoid offsetting an unrelated invoice

Different payout currency

Obtain the documented conversion details

Separate FX effects from customer shortfalls

Missing statement credit

Check payout status and receiving-account evidence

Retain the amount in transit

Technical units deserve a check before staff investigate an apparent shortfall. Stripe's balance transaction amounts use the smallest currency unit. An API amount of 100000 therefore represents €1,000.00 for EUR, while a decimal CSV field may already show 1000.00.

Dates can disagree without a missing payment. A batch closing late on Friday might appear on a receiving statement after the weekend. Compare the processor's reporting timezone with the account's booking date before extending an ageing alert.

Status labels also need care. Stripe sends a payout.paid event when funds are expected to be available in the destination account. A later failure notification is still possible. The statement credit supplies separate evidence that finance needs for the final cash match.

Close an exception only when its investigation leaves a traceable resolution. Record the source reference and reviewer, including the reason for any manual override. A successful match should remain explainable after staff change roles.

Put a daily reconciliation routine into operation

Run the process in a fixed order and reconcile the residual PSP balance as well as received cash. Proving a deposit alone leaves pending transactions outside the review.

Daily checks and controlled automation

Start by retaining dated source exports. The operator should record the report version and timezone, then compare opening balances with the previous completed run. A missing file must trigger an alert. Treat the run as incomplete.

Apply exact identifier matches before considering suggested allocations. Automated invoice reconciliation needs controls for duplicate imports and repeated notifications. One external event should create one financial effect, even if the integration receives it several times.

The implementation should keep its own unique event key and processing log. If a source changes an existing item, keep the correction history so reviewers can reconstruct each change.

A webhook reconciliation integration can deliver updates between scheduled checks. During an interruption, finance should use report exports to continue reconciliation. When updates resume, compare those exports with the integration’s processing log to identify missed activity.

A daily sign-off should confirm:

  • Customer allocations agree with the underlying receipts.

  • Each batch has an explained net amount.

  • Arrived payouts match statement credits by currency.

  • The residual PSP balance agrees with its source report.

  • Open differences have an owner and review date.

During rollout, test one settlement cycle before replacing every receiving instruction. Include a split payment and a refund in the sample. A duplicate import should leave balances unchanged. Missing identifiers need review.

For period cut-off and foreign-currency revaluation, the close team can follow the month-end checklist. Daily matching should leave an evidence trail that the close team can use without rebuilding the month's allocations.

A UK multi-currency account for a corporate invoicing provider with PSP settlements works best within an agreed operating model. Use a pilot reconciliation to test that operating model. At go-live, require a signed reconciliation for at least one complete batch, with evidence for every deduction and any remaining amount in transit. Reviewers should be able to trace every matched amount to source records. Keep the completed reconciliation and its supporting exports available to the team. Finance can use that pilot to decide whether the proposed setup fits its daily workload before moving further activity to new receiving details.

FAQ

Can a corporate invoicing provider reconcile PSP settlements by invoice and currency?

Yes. A stable identifier links each customer collection to its allocation against the relevant bill, even when several receipts arrive in a single transfer. Finance then matches the payout to the statement credit. Keep records for each currency separate so unrelated balances do not cancel each other.

How do invoicing platforms match incoming PSP payouts to open invoices?

They allocate customer payments first. A batch ID then links the receipts and any adjustments to the net deposit. Several bills can sit behind one transfer, so an amount-only match can allocate cash incorrectly.

What reference data is needed to reconcile multi currency settlements?

Retain the legal entity, invoice ID, PSP transaction ID, payout reference, amounts, currency codes and relevant dates. Record the original transaction ID for each adjustment. Export scope matters because metadata available in one report may be absent from another.

Is one account per currency better than a single multi currency balance?

Neither label establishes suitability. The preferred structure must provide supported receiving details and clear reporting for every denomination the processor will pay out. One interface can contain several accounts. Check destination requirements and sample exports before choosing a provider.

About the event

ornament

Power your payments
with EQWIRE

Create your account in minutes and experience smooth, secure global payments.

A modern approach to global payments — seamless, compliant, and built for
the digital era.

EQWIRE is a UK Electronic Money Institution (EMI) authorised, regulated and supervised by the Financial Conduct Authority (EQWIRE UK Limited, the firm reference number is 901100). Whilst Electronic Money products are not covered by the Financial Services Compensation Scheme (FSCS) your funds will be held in one or more segregated accounts and safeguarded in line with the Electronic Money Regulations 2011 – for more information please see How We Protect Your Money page.










For data protection purposes, EQWIRE is registered with the Information Commissioner’s Office as an independent data controller. EQWIRE’s registration reference number is ZA805830.










Copyright 2026 EQWIRE. All rights reserved. EQWIRE name and logo are registered EU trademarks (registration numbers are 018396653 and 018396654). EQWIRE is the trade name of EQWIRE UK Limited, a company registered in England (company registration number is 12533411).









We do not position EQWIRE as a general retail bank. Personal accounts are intended for professionally active individuals who fit our risk appetite.

EQWIRE does not facilitate transactions involving crypto currencies.

Developed by wsa.design

A modern approach to global payments — seamless, compliant, and built for the digital era.

EQWIRE is a UK Electronic Money Institution (EMI) authorised, regulated and supervised by the Financial Conduct Authority (EQWIRE UK Limited, the firm reference number is 901100). Whilst Electronic Money products are not covered by the Financial Services Compensation Scheme (FSCS) your funds will be held in one or more segregated accounts and safeguarded in line with the Electronic Money Regulations 2011 – for more information please see How We Protect Your Money page.










For data protection purposes, EQWIRE is registered with the Information Commissioner’s Office as an independent data controller. EQWIRE’s registration reference number is ZA805830.










Copyright 2026 EQWIRE. All rights reserved. EQWIRE name and logo are registered EU trademarks (registration numbers are 018396653 and 018396654). EQWIRE is the trade name of EQWIRE UK Limited, a company registered in England (company registration number is 12533411).









We do not position EQWIRE as a general retail bank. Personal accounts are intended for professionally active individuals who fit our risk appetite.

EQWIRE does not facilitate transactions involving crypto currencies.

Developed by wsa.design

A modern approach to global payments — seamless, compliant, and built for the digital era.

EQWIRE is a UK Electronic Money Institution (EMI) authorised, regulated and supervised by the Financial Conduct Authority (EQWIRE UK Limited, the firm reference number is 901100). Whilst Electronic Money products are not covered by the Financial Services Compensation Scheme (FSCS) your funds will be held in one or more segregated accounts and safeguarded in line with the Electronic Money Regulations 2011 – for more information please see How We Protect Your Money page.









For data protection purposes, EQWIRE is registered with the Information Commissioner’s Office as an independent data controller. EQWIRE’s registration reference number is ZA805830.









Copyright 2026 EQWIRE. All rights reserved. EQWIRE name and logo are registered EU trademarks (registration numbers are 018396653 and 018396654). EQWIRE is the trade name of EQWIRE UK Limited, a company registered in England (company registration number is 12533411).









We do not position EQWIRE as a general retail bank. Personal accounts are intended for professionally active individuals who fit our risk appetite.

EQWIRE does not facilitate transactions involving crypto currencies.

Developed by wsa.design