System Integration Consultant, USA

Bank connections: ACH, positive pay and remittances

Banking is where an integration error costs real money fastest, so I treat it first. US banks each publish their own requirements for payment files, and the ERP's standard export rarely matches every bank without adjustment. The design covers:

• ACH payment runs. Which vendor bank details the ERP holds, who can change them, how the file is generated and approved, and how the bank's acknowledgment or rejection comes back.
• Positive pay. The issued-check file sent to the bank after each check run, including voids, so fraud screening has accurate data.
• Customer receipts. Lockbox or remittance files imported and matched to open invoices, with rules for short payments and unapplied cash.
• Statement feeds. Bank feeds or statement imports used for reconciliation, with a clear rule on which transactions are matched automatically and which need review.

Vendor bank details deserve a control of their own. A change to remittance details is a common route for payment fraud, so I specify who may edit them, what verification is required and how the change is logged. Every bank file is tested with the bank's own validation process before go-live, and finance signs off a parallel run. Your bank and your controller confirm the final setup; I make sure the questions are asked and the answers are written down.

Shopify, Amazon and card processor settlements

Online sales create two separate integration problems that often get treated as one. The first is the order: customer, items, shipping address, discounts and tax, which the ERP needs for fulfillment and inventory. The second is the money: the processor or marketplace pays out a net amount after fees, refunds, chargebacks and reserves, often days later and covering many orders at once.

I design the two flows separately. For orders, I agree whether each sale creates its own ERP order or whether high-volume channels post daily summaries, how SKUs on Shopify or Amazon map to ERP items and bundles, and what happens to an order for an item the ERP does not recognize. For settlements, I specify how each payout report is broken down into sales, fees, refunds and adjustments, posted to clearing accounts and matched to the deposit in the bank feed.

Marketplace sales add a tax question. Where a marketplace collects and remits sales tax on your behalf, the ERP must record those sales differently from direct ones so returns are not overstated. Your CPA confirms the treatment; I make sure the integration carries the flag that distinguishes the two. The same approach applies to Stripe, Square and other processors behind a trade portal or invoice payment link. For channel-heavy businesses, the ecommerce industry page covers the wider system design.

Sales tax engines, payroll providers, EDI and warehouses

Beyond banking and commerce, four other connections appear in most US designs:

• Sales tax engine. Many companies selling into several states connect a tax engine such as Avalara to the ERP. The integration needs product tax codes kept in sync, customer exemption status passed on each transaction, and committed invoices sent back so the filing data matches the ledger. Collection and filing obligations are your tax advisor's call; the integration simply carries the data.
• Payroll. Payroll usually stays with a specialist provider. The ERP receives a summarized journal mapped to entities, departments and jobs, and the mapping is checked every time a new department or earnings code appears.
• EDI. Large retailers and distributors often require purchase orders, ship notices and invoices in EDI through an EDI provider. Each trading partner has its own guide, so I map fields partner by partner and plan for compliance testing before live orders flow.
• Third-party warehouses. A third-party warehouse needs released orders and item data, and returns shipment confirmations, tracking numbers and inventory snapshots. I specify a daily inventory comparison so stock differences are found before customers notice.

Each of these is written as a flow specification with trigger, direction, frequency, mapping, error conditions and a business owner, which is the document developers build from and testers test against.

Native connector, middleware or custom API

There is no single right method, and most US designs end up with a mix. I make the decision per flow rather than per project:

Whatever the method, I require the same controls: validation before records are written, retries with limits, protection against duplicate orders or payments when a message is resent, error queues that reach a named person and a daily reconciliation of counts and totals between systems. A connector that cannot show its own errors is not finished, however quickly it was installed.

When a connector exists, I test it against your real scenarios before anyone relies on it. The general approach is set out on my ERP integration page.

Splitting the work: design, build, sign-off and support

Integration projects go wrong when nobody is clearly responsible. I make the split explicit at the start:

• My part: requirements, data ownership rules, field mappings, method choice, test scripts, review of the build against the specification, coordination of testing with the bank, EDI provider or warehouse partner, and go-live readiness.
• Developers or the partner: building, deploying and documenting the code, connectors and middleware flows, and fixing defects found in testing. Where a flow only needs a native connector switched on or a light low-code automation, setting it up can sit within my own scope.
• Your team: business sign-off, reconciliations during parallel runs, and day-to-day ownership of each flow once live.

Testing follows full business scenarios: an Amazon order picked by the warehouse partner, invoiced, settled by the marketplace and reconciled to the bank deposit. Cutover is planned flow by flow, with a short period of closer monitoring after go-live. Each flow then has a named owner, a runbook and an alert route.

The engagement is remote, with working sessions scheduled for overlap with your main US time zone, and on-site visits by arrangement only. For the CRM side of the picture, see my CRM consultant USA page; for broader ERP advice, the ERP consultant in the USA page and the US overview. The wider method is on system integration.