Skip to content
XSIS
Talk to an engineer

Integrations

ERP and banks

ERP to bank: payment files out, statements back, reconciled

Payments sent as ISO 20022 pain.001 over host-to-host SFTP or bank APIs, with camt.053 and MT940 statements matched back to the ledger.

Talk to an engineerSee engagement options

Blueprint

ERP to bank: payments out, statements inApproved payments leave the ERP as signed ISO 20022 files over a host-to-host channel. Status reports and statements come back the same way and are matched to open items. Rejections and unmatched lines go to your team with the reason attached.ERPERPPayment runs, openitems, general ledgerXSISIntegration layerMapping, validation,signing andschedulingGatewaySecure bankchannelHost-to-host SFTP,EBICS or bank APIBankBankPayments and cashmanagementServiceReconciliationengineMatching rules andtolerancesPeopleTreasury andfinance teamReviews rejectionsand breaks1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002RJCT910

ERP to bank: payments out, statements in

Approved payments leave the ERP as signed ISO 20022 files over a host-to-host channel. Status reports and statements come back the same way and are matched to open items. Rejections and unmatched lines go to your team with the reason attached.

  • Primary flow
  • Asynchronous
  • Exception path

The flow, step by step

  1. From ERP to Integration layer: Approved payment run, over REST/JSON · IDoc (primary flow).
  2. From Integration layer to Secure bank channel: Signed and encrypted payment file, over ISO 20022 pain.001 · OpenPGP (primary flow).
  3. From Secure bank channel to Bank: Delivered to the bank, over SFTP H2H (primary flow).
  4. From Bank to Secure bank channel: Status reports and statements, over pain.002 · camt.053 · MT940 (asynchronous).
  5. From Secure bank channel to Integration layer: Collected and validated, over SFTP H2H (asynchronous).
  6. From Integration layer to Reconciliation engine: Statement lines, over camt.053 (asynchronous).
  7. From Reconciliation engine to ERP: Matched entries posted, over REST/JSON (primary flow).
  8. From Integration layer to Treasury and finance team: Rejected payments, with the reason code, over pain.002 RJCT (exception path).
  9. From Reconciliation engine to Treasury and finance team: Unmatched lines: a reconciliation break (exception path).
  10. From Treasury and finance team to ERP: Corrected and resubmitted (exception path).

Overview

This is the flow between an ERP and its banks: approved payments go out, and status reports and statements come back. It is the connection most finance teams still run by hand, through banking portals and spreadsheets, and the one where an error costs money.

The reference design puts an integration layer between the ERP and each bank. The layer maps payments into the bank’s variant of ISO 20022 pain.001, signs and encrypts them, and delivers them over host-to-host SFTP, EBICS or the bank’s API. Status reports and statements return the same way and are matched to open items in the ERP.

The failure path is designed as carefully as the happy path. A rejected payment comes back with the bank’s reason code. A statement line that does not match becomes a reconciliation break for a named person to clear. Nothing is dropped and nothing is posted twice.

How the flow works

  1. 01

    Approve the payment run

    Your ERP produces the payment run and your approvers release it, as they do today. The integration layer picks up only approved runs.

  2. 02

    Map, sign and encrypt

    The layer maps each payment into the bank’s pain.001 variant, validates it, and signs and encrypts the file as the bank requires.

  3. 03

    Deliver to the bank

    The file travels over the agreed channel, host-to-host SFTP, EBICS or the bank’s API, before the bank’s cut-off time.

  4. 04

    Receive status and statements

    The bank returns pain.002 status reports for each file and payment, and camt.053 or MT940 statements at the end of the day.

  5. 05

    Collect and validate

    The layer collects each report, checks it for gaps and duplicates against the statement sequence, and parses it into lines.

  6. 06

    Match and post

    Statement lines are matched to open items with the rules you approved, and matched entries are posted to the ERP.

When something fails

A payment is rejected

The pain.002 report carries the bank’s reason code. The payment is marked rejected in the ERP and sent to your treasury team to correct and resubmit.

A statement line does not match

The line becomes a reconciliation break with the likely candidates and the reason it failed. Your team clears it, and the rules can learn from it.

A file is missing or late

Statement sequence numbers and expected delivery times are checked. A missing or late file raises an alert before anyone relies on the cash position.

A key or certificate is about to expire

Signing keys and channel certificates are tracked with their expiry dates, and renewal starts early enough to agree the new key with the bank.

Standards and systems

Banking standards and channels
  • ISO 20022
  • pain.001
  • pain.002
  • camt.052
  • camt.053
  • camt.054
  • MT940
  • MT942
  • SFTP (H2H)
  • EBICS
  • SWIFT
  • OpenPGP

Questions and answers

Host-to-host, EBICS or bank APIs: which should we use?

The bank usually decides. Host-to-host SFTP is the most widely offered channel for corporate payment files. EBICS is common with banks in Germany, France and neighbouring countries. Bank APIs suit real-time balances and instant payments where the bank offers them. Many companies use more than one, and the integration layer hides the difference from the ERP.

Link to this question
Should we receive camt.053 or MT940 statements?

Where the bank offers both, camt.053 carries richer, structured remittance data, which makes automatic matching more reliable. MT940 is still widely used and works well for many cases. We can take both, convert them into the same internal model, and move each bank from MT940 to camt.053 when it suits you and the bank.

Link to this question
Can we see our cash position during the day?

Yes, if your banks provide intraday reports. They come as camt.052 or MT942 messages, or through a balance API. We collect them on the schedule each bank supports and show them beside the end-of-day statements, so your treasury team can see expected and actual positions before the cut-off times.

Link to this question
Can we trace who approved and sent a payment?

Yes. Approval stays in your ERP with its existing controls. The integration layer logs every file it creates, signs, sends and receives, with timestamps, identifiers and the technical account used. That log links each payment in the bank’s status report back to the ERP document and its approvers.

Link to this question
We have several banks. Is each one a separate project?

No. The integration layer, the internal payment model and the matching rules are built once. Each new bank adds its own format variant, channel and onboarding steps, which are smaller pieces of work. We usually connect the bank with the most volume first and add the others in order.

Link to this question
How is the connection tested before go-live?

Each bank provides a test environment or a test process. We agree a set of test cases with the bank, covering each payment type, rejections and statements, run them, and keep the evidence. When the bank signs off, we go live with a small first payment run and compare the results before moving the rest.

Link to this question

Tell us what you need to build or connect.

Describe the systems, the timeline and the constraints. The right engineers take it from there.

Talk to an engineerSee how we work
  • Our team will call you within 24 hours during your preferred time slot
  • Our team is available 24/7