An order can look correct in Shopify while carrying the wrong delivery service into the warehouse system. Stock can update in one direction but not the other. An invoice may post with the right total but the wrong VAT treatment. These are the operational gaps an integration testing checklist is designed to expose before they reach customers, finance teams or the dispatch bench.

For retailers, wholesalers and distributors, integration testing is not simply a technical task for the final days of a project. It is the controlled proof that the agreed process works across the systems people rely on: ERP, eCommerce, marketplaces, warehouse software, courier platforms and finance processes. A connection is only ready for use when it handles normal trading, exceptions and recovery in a way the business can operate confidently.

Start with the business process, not the field mapping

A field mapping shows that `customer email` is sent from one system to another. It does not show whether a customer should be created, matched to an existing account, held for review or rejected when the email address is missing. Testing needs to follow the real journey of a transaction.

Take a web order flowing from Shopify into Sage 200 or SAP Business One. The test should confirm more than the presence of an order record. Does the correct customer account apply? Are trade prices, promotional discounts, VAT, carriage, gift messages and delivery instructions represented correctly? Does the order reach the right warehouse or fulfilment route? Is stock reserved at the intended point in the process?

Before testing begins, agree the scope in operational terms. Specify which systems are involved, which processes are in and out of scope, what initiates each transfer, and which system is the source of truth for each data type. Pricing, stock, customer records and product information often have different owners. Leaving this unclear creates the kind of issue that can appear to be a software fault when it is actually a design decision that was never made.

Integration testing checklist: prepare the right test cases

A useful checklist should be based on representative records, not a handful of convenient examples. Include products with variations, bundles, discontinued lines, zero stock, different VAT treatments and unusual weights or dimensions where these affect delivery. Use test customers that represent both guest checkout and established trade accounts, including customers with multiple delivery addresses.

Your test set should also cover the cases operations teams deal with every week:

• A standard paid order with a single stocked item.
• A multi-line order containing different VAT rates, discounts or delivery charges.
• An order with insufficient stock, a back-order or a discontinued product.
• A cancelled order, partial shipment, partial refund or amended delivery address.
• A new customer, an existing customer and a record with incomplete or invalid data.
• A marketplace order where the channel reference, payment position and fulfilment method differ from the website.

The exact cases depend on the operating model. A wholesale business may need to test account-specific price lists, credit limits and sales order approval. A retailer shipping direct to consumers may place greater emphasis on delivery-service selection, labels, tracking updates and customer communications. Neither approach is more thorough by default. The right checklist reflects the transactions that carry the greatest volume, value or risk.

Define expected results before running the test

Each case needs a clear expected outcome. “Order transferred successfully” is too vague to be useful. Define the result in every relevant system, including the status, values, references and any required action by a person.

For example, a successful order test may require an order to appear in the ERP with the original web order number, correct lines and prices, the required delivery method, a valid customer record and a status ready for warehouse processing. Once despatched, the courier tracking number should return to the eCommerce platform or marketplace where appropriate. If an invoice is generated from the shipment, its totals and tax treatment should reconcile to the original order.

Agree who will confirm each result. IT may verify that messages were processed, but warehouse, finance and customer service colleagues are often best placed to decide whether the resulting transaction is usable.

Check data quality and ownership at both ends

Integration can reveal problems that have lived unnoticed in source data for years. Duplicate customer accounts, inconsistent SKUs, missing postcodes and outdated product attributes may all produce incorrect matching or failed transfers.

Test how records are matched. A customer could be identified by account code, email address, company name or a combination of fields. Each option has trade-offs. Email matching may work well for consumer orders but be unsuitable for a trade customer with several buyers. Matching on company name risks duplicates caused by spelling variations. Where automated matching is not sufficiently reliable, the process should have a defined exception route rather than creating uncertain records automatically.

Product matching deserves the same attention. Confirm which SKU, barcode or internal item code is authoritative, and test variations such as size and colour where each variation is a separate stock item. If product data is sent to an eCommerce platform, check that the integration does not unintentionally overwrite descriptions, images or merchandising changes managed by the eCommerce team.

Test timing, sequencing and stock behaviour

Many integration faults are timing faults. A stock update may be technically correct but arrive after a customer has bought the last available item. A despatch update may leave the warehouse before the order acknowledgement reaches the customer service team. Testing must therefore include the order in which events happen, not only their content.

Confirm how frequently each process runs and whether it is event-driven, scheduled or manually triggered. Then test what happens when two changes occur close together. For example, amend an order after it has been passed to the warehouse, or receive a stock adjustment while an order is being allocated. The expected response might be an update, a hold, a cancellation or a task for a colleague. It should never be assumed.

Stock requires particular care in multichannel trading. Check available stock, allocated stock, physical stock and stock in transit where those measures are used. A business may choose to publish a buffer to Amazon, eBay or its website to reduce overselling. That is an operational rule to test and approve, not an arbitrary integration setting.

Test failures, retries and exception handling

A process that works only when every platform is available and every record is perfect is not ready for day-to-day trading. Deliberately test invalid postcodes, missing product codes, blocked customer accounts, API time-outs and unavailable destination systems where this can be done safely in a test environment.

For each failure, establish three things: whether the error is visible, whether the transaction can be retried without duplication, and who owns the next action. If a courier label request fails, can the warehouse team identify the affected order quickly? If an ERP connection is temporarily unavailable, are orders queued and processed once the service returns? If an order is resent, does the ERP recognise the original reference and avoid creating a duplicate?

Clear exception reporting is often more valuable than a perfectly clean technical log. The person resolving an issue needs enough information to find the order, understand why it stopped and know whether correction belongs with customer service, finance, warehouse operations or IT.

Reconcile the end-to-end result

Testing should include reconciliation, particularly where orders lead to financial postings. Compare order line values, discounts, delivery charges, VAT, refunds and invoice totals across the relevant systems. Confirm that document references make it possible to trace one transaction from the sales channel through to ERP and fulfilment.

Do not overlook volume testing where order peaks are material. A modest test can prove a mapping but may not reveal delayed queues, rate limits or operational bottlenecks during a busy promotion or seasonal period. The purpose is not to chase an artificial maximum. It is to test a credible level of trading activity and establish how the process behaves if there is a backlog.

Security and access also need a practical review. Service accounts should have only the permissions required for the agreed process, while test data should be handled carefully, particularly where it includes customer contact details. The right controls vary by system and integration method, but access should not be an afterthought once data begins moving between platforms.

Obtain operational sign-off before go-live

The final checklist should result in a shared decision, not a technical assumption. Capture passed and failed cases, outstanding issues, workarounds, owners and any accepted limitations. A minor cosmetic discrepancy may be acceptable at go-live; an order that can be invoiced twice is not.

Plan the first period of live monitoring as part of the test approach. Decide which orders will be checked, who reviews exceptions, how often reconciliations are run and how an urgent issue is escalated. This is especially useful when integrations replace manual entry, because teams need confidence in the new process before they stop maintaining parallel checks.

Harmonise Solutions can help businesses turn these operational scenarios into a practical test plan for ERP, eCommerce, marketplace, warehouse and courier integrations. The most useful testing is not about proving that systems can exchange data. It is about proving that your people can fulfil, invoice, support and reconcile real orders when trading is at its busiest.