Skip to content
XSIS
Client AreaRequest a Proposal
People working at computers in a bright office

Enterprise Applications & Integration

ERP Implementation and Integration

Your ERP at the centre, with every record it needs arriving once.

Talk to Our Team

Why It Matters

An ERP holds the orders, stock, invoices and ledger the business runs on, and most of the data it needs arrives from elsewhere.

Dirty master data and a migration that moves every connection at once are the usual ways this fails. We agree who owns each record, clean data before it moves, and switch flows one at a time.

What We Do

  • ERP Implementation and Migration

    We set up the ERP, configure the modules you use and move the opening balances, with each process tested by your team before go-live.

  • Links to Your Other Systems

    We connect the ERP to banks, stores, carriers and tax platforms through their published interfaces, each link with a named owner.

  • Order, Invoice, Inventory and Payment Sync

    Orders, invoices, stock and payments move between systems without rekeying, and a failed record waits for a person instead of being lost.

  • Data Mapping and Migration

    We profile the old records, agree the rules for duplicates and gaps, and rehearse the move on a copy before you check the final counts.

  • Monitoring and Support

    We watch each flow, alert the right team and replay failed messages, and the runbook stays with you.

What Changes for You

  1. One Record, Posted Once

    Orders, invoices, stock and payments reach the ledger once, and a retry cannot post the same record twice.

  2. A Migration Without a Cliff

    Flows move to the new ERP in steps while the old route stays open until the new one is proven.

  3. Every Failure Visible

    A failed message is kept with its reason, so your team can see it and replay it.

Systems We Connect

We connect the ERP to the systems that feed it and the systems that use its records.

  • The ERP

    We implement the ERP, configure the modules you use and keep the records it owns.

  • Banks and Payment Files

    Payments leave and statements return through the channels each bank supports.

  • Stores and Sales Channels

    Orders, stock and prices reach the ERP from every place you sell.

  • Tax and Reporting

    Invoices and tax data go to the platforms that check them, with a reason for every rejection.

  • Carriers and Suppliers

    Dispatch, receipt and stock updates arrive without a person retyping them.

How It Connects

One drawing follows a payment from the ERP to a bank. The other follows records to partners and back.

ERP to Bank: Payments Out, Statements InApproved payments leave the ERP as signed payment 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 filetransfer or bank APIBankBankPayments and cashmanagementServiceReconciliationengineMatching rules andtolerancesPeopleTreasury andfinance teamReviews rejectionsand breaks1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP to Bank: Payments Out, Statements In

Approved payments leave the ERP as signed payment 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 in 10 steps

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).
ERP to Third Parties: One Platform, Many PartnersBusiness events leave the ERP once and the integration platform delivers them to each partner in the format it expects. Callbacks come back the same way. A message that still fails after its retries goes to a dead-letter queue and raises an alert with the payload attached.ERPERPCustomers, orders,invoicesXSISIntegration platformiPaaS or customservices, mapping andretriesThird partyCRMAccounts, contactsand opportunitiesThird partyLogistics andcarriersShipments andtrackingThird partyE-invoicing andtax platformClearance andreportingThird partyKYC and identityproviderVerification andscreeningServiceDead-letter queueand alertsNothing is droppedPeopleSupport team1REST · OData · webhook2REST/JSON3REST/JSON4webhook5SOAP/XML · REST6REST/JSON7webhook89

ERP to Third Parties: One Platform, Many Partners

Business events leave the ERP once and the integration platform delivers them to each partner in the format it expects. Callbacks come back the same way. A message that still fails after its retries goes to a dead-letter queue and raises an alert with the payload attached.

  • Primary flow
  • Asynchronous
  • Exception path
The flow in 9 steps

The Flow, Step by Step

  1. From ERP to Integration platform: Business events, over REST · OData · webhook (primary flow).
  2. From Integration platform to CRM: Customers and orders, over REST/JSON (primary flow).
  3. From Integration platform to Logistics and carriers: Shipments booked, over REST/JSON (primary flow).
  4. From Logistics and carriers to Integration platform: Tracking events, over webhook (asynchronous).
  5. From Integration platform to E-invoicing and tax platform: Invoices for clearance, over SOAP/XML · REST (primary flow).
  6. From Integration platform to KYC and identity provider: Identity checks, over REST/JSON (primary flow).
  7. From KYC and identity provider to Integration platform: Check results, over webhook (asynchronous).
  8. From Integration platform to Dead-letter queue and alerts: Failed after retries, to a dead-letter queue (exception path).
  9. From Dead-letter queue and alerts to Support team: Alert with the payload and the error (exception path).

Go-Live and Switch-Over

Every stage has a decision for you and a piece of evidence we must show. The old path stays available until you accept the new one.

  1. Fix the Scope

    You agree the flows in the first release, the records each one owns and the order they move.

  2. Rehearse on a Copy

    You provide a test copy and a named owner for each flow. We run the messages and show you the exceptions.

  3. Switch One Flow

    The first flow goes live in a planned window. You accept the result before the next one starts.

  4. Check the Totals

    Your finance team compares the first postings with the source records. We fix every difference before the next flow.

  5. Hand Over

    You receive the mappings, the runbook and the test evidence. Your team can run the route, or we can.

Compliance in Every Market

Tax and reporting rules change while the ERP stays in place. We keep the controls that apply to every market in one layer.

Each market's formats and codes sit at the edge. A change there does not touch the core postings. Every connection keeps a record an auditor can follow.

Read the Country Guides

Client Stories

Platforms and Technologies

SAP, Oracle, Microsoft, Odoo and Sage are the ERP systems we implement. REST is the common web interface for reading and changing a record. OData is the same idea for data that follows a published model. IDoc is SAP's own document format. EDI carries orders and invoices between trading partners, and AS2 is a secure way to send those files. ABAP is SAP's own programming language.

Languages
  • ABAP
ERP systems
  • SAP S/4HANA
  • SAP ECC
  • SAP Business One
  • Oracle Fusion Cloud ERP
  • Oracle NetSuite
  • Microsoft Dynamics 365 Finance and Supply Chain Management
  • Microsoft Dynamics 365 Business Central
  • Odoo
  • Sage Intacct
  • Sage X3
Integration
  • SAP IDoc
  • OData
  • REST
  • EDI (EDIFACT, ANSI X12)
  • AS2

Naming a product does not mean a partnership with its vendor.

Industries

Insights

Questions

The questions finance and IT teams ask before they change an ERP.

Where do we start?

We review the flows you have and the records they move. You choose the first flow and the outcome it must reach. We then write the scope and the acceptance checks with you.

Link to this question

How long does an ERP migration take?

It depends on the flows in the first release, the state of the data and the number of partners. We plan in stages, so one flow can go live before the rest are built. You see the plan after the review.

Link to this question

Who owns the integration work?

You do. The contracts, mappings, tests and runbooks are yours at hand-over. We work in your code repositories and keep credentials in your vault. If we run the service, the same documents stay with you.

Link to this question

What drives the cost?

The number of flows, the systems on each side, the quality of the data and the partner testing each flow needs. ERP licences and partner fees are separate. We estimate each flow so you can phase the work.

Link to this question

What is not included?

ERP licences, hardware and network changes are not part of our scope. We do not change a vendor's product or promise a partner's approval. We name those dependencies in the plan, with who owns each one.

Link to this question

Visit the Knowledge Base

Tell Us What You Need to Run, Build or Secure.

Describe the service, the systems and the pressure you are under. The right team takes it from there.

Talk to Our Team