Integration Consultant, South Africa

Bank integration in South Africa: files, portals and approvals

Banking is usually the first integration South African finance teams ask about, and the answer depends heavily on the bank. Each bank has its own options for business clients: file layouts for supplier payment batches and debit order collections, statement export formats, host-to-host links for larger accounts and, increasingly, APIs. Which of these is available for your account type and package is something I confirm with your bank relationship team early, rather than assume.

The design then covers:

• Payments: how the ERP produces a batch in the bank's layout, where it is approved and how the approved batch is released, so authorization rules are not weakened by automation.
• Debit order collections: how mandates are recorded, how collection files are generated, and how unpaid and disputed items come back into the ledger. The rules governing mandates are set by the banking system and should be confirmed with your bank.
• Statements: how often they are imported, the matching references used and how unmatched items are handled.
• Verification: how new or changed supplier bank details are checked before the first payment, a common point of fraud.

Bank details are personal or sensitive information in many cases, so access is limited and changes are logged with POPIA in mind. The goal is that payments, collections and statements move without retyping, while controls remain at least as strong as before. The general approach is on my ERP integration page.

Payroll, imports and the data your accountant needs for SARS

Payroll in South Africa usually stays with a specialist payroll product or bureau, which calculates PAYE, UIF and other deductions and handles the related submissions. The ERP does not need individual payslips. It needs a summarized journal by cost center, department or project, mapped to the general ledger once and checked against the payroll report each period. That mapping is agreed with your financial director, along with the transport: an exported file, a direct API call or a ready-made connector between the two products.

Imports are another area where integration saves real effort. Landed cost typically includes the supplier invoice, freight, insurance, customs duties, import VAT and the clearing agent's fees, often arriving on separate documents and at different times. I specify how this data reaches the ERP, how it is allocated across the shipment and when costs are finalized, so stock is valued consistently and margins are not distorted.

Neither flow submits anything to SARS on its own. The point is that VAT, import and payroll figures in the ledger can be traced back to source documents when your accountant prepares returns or answers a query. SARS has also been consulting on electronic invoicing and reporting; keeping invoice and customer data structured now reduces rework if those plans become requirements. Which obligations apply, and when, is for your tax advisor to confirm.

Retailers, stores and online channels

Suppliers to large South African retailers often receive orders through EDI or a retailer's supplier portal, and must return delivery confirmations and invoices in the same way. When these are keyed by hand, errors in item codes, store codes or prices lead to short payments and claims that take months to resolve.

The integration design for retail customers covers:

• mapping the retailer's item and store codes to your own, and who maintains that mapping when ranges change
• price checks against the agreed cost price before an order is accepted
• delivery confirmations that reflect what was actually shipped, including short deliveries
• invoice and credit note formats each retailer accepts
• remittance advice imported and matched, so deductions are visible and can be challenged

Businesses with their own stores face a different set of flows: POS sales, returns and payments sent to the ERP, stock updates in both directions and takings reconciled with bank deposits. Online stores on Shopify or WooCommerce add orders, refunds and gateway settlements, and courier systems can return tracking and proof of delivery.

Every retailer and channel gets its own specification, and testing uses genuine orders, remittances and returns from that retailer rather than invented examples. If the sales process feeding these orders also needs attention, see my CRM consulting for South African businesses.

Designing integrations that survive load-shedding and connectivity loss

In South Africa, an integration design that assumes constant power and connectivity is incomplete. Stores, warehouses and offices lose power or internet for hours at a time, and on-premise servers or routers without backup power take connections down with them. The question is not whether interruptions happen, but how each flow behaves when they do.

I write specific requirements for this:

• Queuing: data created while a site is offline is stored locally and sent when the connection returns, in the right order.
• Idempotency: a message resent after an interruption does not create a second order, payment or stock movement.
• Retries with limits: temporary failures are retried automatically, but a record that keeps failing goes to an error queue for a person.
• Hosting choices: middleware and custom services hosted in the cloud rather than on a server in a building that may lose power, with the data location noted for POPIA purposes.
• Recovery checks: after an outage, simple control totals confirm that each site's sales, stock and payments have caught up.

Testing then includes deliberate interruptions. We disconnect a test POS or pause a connector mid-transfer and confirm that the data recovers correctly. This is far cheaper to discover in testing than after a busy trading day. The broader testing approach follows my ERP testing and UAT method.

Roles, methods and support after go-live

South African integration projects often involve more parties than expected: the ERP implementer, a payroll bureau, the bank's onboarding team, a retailer's EDI provider and sometimes a clearing agent's system. I put the responsibilities in writing in the first week. My side covers the integration design, master data ownership, the interface specifications, the method recommendation for each flow, checking what the builders deliver and the test plan. Building is done by whichever party will support the result: the implementer, your developers, an independent developer or the bank or retailer's own onboarding process.

Choosing the method depends on the flow. A connector bundled with your accounting system or ERP comes first if it truly handles your cases. An integration platform such as Zoho Flow, Make or n8n is worth its subscription when many systems exchange the same data and somebody in the business administers it. Custom services fit heavy volumes or unusual rules, but they need a long-term code owner. For many bank and retailer links, an automated and monitored file exchange is still the normal answer.

Where Sage, Pastel or another package keeps some functions, the design records which records each system owns and how they stay in step.

Handover includes a named alert recipient, a troubleshooting guide and a support clause with expected response times. Everything is delivered remotely. My ERP consulting for South African firms and the South Africa hub describe related work.