ERP–WMS Integration Test Cases: A UAT Script Teams Can Run

The interface passed system testing, the demo looked clean, and on the second day of live operation the finance team found 440 eaches missing from inventory value. Nobody had lost stock. A receipt of 40 cases had been posted to the ERP as 40 eaches because the unit-of-measure code on the WMS message never matched the conversion table. No test case had asked for a receipt in cases against a purchase order raised in eaches.

This article gives integration teams a user acceptance test (UAT) script they can run as written: about 40 numbered cases across item master, receipts, putaway, outbound confirmations, returns, adjustments, message failures and cutover. Each case has an expected ERP posting, the evidence to keep and a pass rule. The catalogue ends with a reconciliation query, a defect severity scale and the exit gates a controller and an auditor will both accept.

What an ERP and WMS acceptance script has to prove

A UAT script proves one thing: every physical event in the warehouse produces exactly one correct posting in the ERP, in the right unit, status and period. Screens that look right are not evidence. The ERP ledger, the WMS inventory table and the message log must agree after every cycle, and the script must say in advance what agreement means.

Most integration testing stops at "the message arrived". Acceptance testing goes further and asks whether the business result is right. A ship confirmation that lands in the ERP but relieves stock from the wrong storage location has arrived. It has also broken the cost of goods sold, the customer invoice and the next cycle count. The cases below are therefore written as business outcomes, not transport checks.

• Positive cases: the normal path with clean data, run first to prove the plumbing and the mapping work for each message family.
• Negative cases: deliberately wrong inputs, such as a cancelled order, an unknown item or an over-receipt, where the pass result is a clear rejection and an exception record, never a silent default.
• Reconciliation cases: a comparison of ERP and WMS balances in base units after each cycle, where the pass result is zero unexplained variance.
• Resilience cases: duplicates, retries, out-of-order arrival and downtime, where the pass result is one posting per business event.

This page is about testing an integration you have already chosen. If the team is still deciding whether warehouse functions should live inside the ERP or in a separate product, start with ERP warehouse management versus a standalone WMS, which covers that buying decision; the script here assumes the decision is made and the interface exists.

Every test family needs one named owner of the record and one person who signs the result. When nobody owns the item master, unit-of-measure defects bounce between the ERP and WMS teams for weeks. Settle ownership before the first case runs, and write it into the script header so testers know whom to call when a case fails.

ERP and WMS acceptance testing supports SOX internal-control audits because PCAOB AS 2201 paragraph B29 lets an auditor rely on an unchanged automated control only when general controls over program changes are effective. A UAT pack with 100% of severity-1 cases passed and signed is the change evidence for the interface.

Item master and unit-of-measure conversion cases

Run item master cases first, because every later case depends on them. A wrong conversion factor does not fail loudly; it posts plausible quantities that are wrong by a factor of 12 or 480. The opening anecdote came from exactly this gap, and a single test receipt in cases would have exposed it.

• IM-01 New item create: create an item in the ERP with base unit EA, case CS = 12 EA and pallet PL = 480 EA. Expected: the WMS holds the same three units and factors within the agreed sync interval. Evidence: ERP change log entry, WMS item screen and the message ID.
• IM-02 Conversion change with stock: change CS from 12 to 10 while the WMS holds 40 CS. Expected: the change is held or rejected with a named error until stock is relabelled or moved; it must not restate on-hand silently.
• IM-03 Missing mandatory attribute: send an item without weight or, for Indian entities, without an HSN code. Expected: rejection to an exception queue with the field named; no default value inserted.
• IM-04 Decimal precision: an item weighed in kilograms to three decimals. Expected: both systems round the same way, and 1,000 picks of 0.333 kg reconcile to the same total.
• IM-05 Item blocked: block an item in the ERP. Expected: the WMS stops allocating it to new waves but still allows receipt and putaway of stock already on the dock.

PCAOB AS 2201 paragraph B30 notes that automated controls can depend on the integrity of tables and parameters, giving a rate table as its example. A unit conversion table plays the same role in a warehouse interface. Treat changes to it as program changes: test them, keep the evidence and do not let anyone edit factors directly in production during UAT.

Inbound cases from ship notice to putaway confirmation

Inbound tests prove that what the supplier said, what the dock counted and what the ERP received all line up. X12 defines the 944 warehouse stock transfer receipt advice as the message a receiving location uses to tell the depositor that a transfer shipment has arrived. Whether you use that set, an API or flat files, the business test is the same.

• IN-01 Full receipt against notice: purchase order of 3 lines, notice matching all 3, dock receives all. Expected: one goods receipt per line, quantities equal, purchase order lines closed for receipt.
• IN-02 Over-receipt within tolerance: receive 102 against 100 with a 2% tolerance. Expected: receipt posts 102 and flags the tolerance use.
• IN-03 Over-receipt beyond tolerance: receive 110 against 100. Expected: WMS blocks or ERP rejects; stock sits in a hold location, not available.
• IN-04 Short receipt: receive 80 of 100. Expected: purchase order keeps 20 open; no automatic closure unless the buyer closes it.
• IN-05 Receipt in cases against an order in eaches: receive 40 CS on an order for 480 EA. Expected: ERP posts 480 EA. This is the case that catches the opening failure.
• IN-06 Receipt against a cancelled order: Expected: rejection with the order number in the error, and an exception record the inbound coordinator can see.
• IN-07 Putaway to quality hold: putaway to a QC location. Expected: ERP stock status is quality inspection, not unrestricted, and the stock cannot be allocated.
• IN-08 Lot and expiry capture: Expected: lot number and expiry date in the ERP batch record match the dock scan exactly.

Outbound cases from order release to ship confirmation

Outbound tests carry the most money, because the ship confirmation usually triggers the goods issue, the cost of goods sold and the customer invoice in one chain. X12 describes the 945 warehouse shipping advice as the message used to reconcile order quantities with shipment quantities, which is exactly what each case below checks.

• OB-01 Full pick and ship: release an order of 10 to the WMS, pick 10, ship 10. Expected: one goods issue of 10, one invoice of 10, order status complete.
• OB-02 Short pick with backorder: ship 8 of 10. Expected: goods issue and invoice of 8; the remaining 2 stay open or backorder according to the customer rule, not cancelled by default.
• OB-03 Split shipment: ship 6 today and 4 tomorrow on two confirmations. Expected: two goods issues, two invoices or one consolidated invoice according to billing rules; total equals 10.
• OB-04 Cancellation after release: cancel the order in the ERP after the WMS has released the wave. Expected: the WMS receives the cancel and stops picking, or the ERP rejects the later ship confirm with an exception.
• OB-05 Orphan confirmation: send a ship confirm for an order the ERP never released. Expected: rejection; no goods issue.
• OB-06 Statutory fields on Indian dispatches: ship a consignment above ₹50,000. Expected: invoice number, invoice date, GSTIN and HSN codes reach the billing document unchanged, so e-invoice and e-way bill steps can run.

The Indian case deserves its own line because the integration can break compliance without breaking stock. CGST Rule 138(1) requires e-way bill information before movement when consignment value exceeds ₹50,000, and the NIC e-invoice specification builds the invoice reference number as a hash of supplier GSTIN, document number, document type and financial year. A truncated or reformatted document number in the ship confirm therefore produces a mismatch downstream.

Returns, adjustments and stock status changes under test

Returns and adjustments move value without a customer order to check them against, so they need tighter tests than outbound. Every case should name the reason code, the stock status after the event and the ledger account the ERP should hit. A pass means the controller can read the posting and know why it happened.

• RT-01 Return in sellable condition: receive against a return authorisation. Expected: stock back to unrestricted, credit note raised for the returned quantity only.
• RT-02 Return damaged: Expected: stock to a blocked or scrap status; credit follows the commercial rule; no sellable stock created.
• RT-03 Return without authorisation: Expected: held in a returns cage with an exception; no credit posted automatically.
• ADJ-01 Count loss with reason code: cycle count finds 3 fewer. Expected: one adjustment of minus 3 with the reason code mapped to the agreed loss account.
• ADJ-02 Adjustment above approval limit: a loss above the value threshold. Expected: held for approval in the ERP; not posted until approved.
• ADJ-03 Status change only: move 5 units from available to damaged. Expected: a status transfer in the ERP; total quantity unchanged.

X12 defines the 947 warehouse inventory adjustment advice as notice of a quantity or status change to inventory records. That definition is useful in UAT because it separates two things testers often merge. A status change must not alter total quantity, and a quantity change must carry a reason. ADJ-03 exists to prove the first rule, and ADJ-01 proves the second.

Duplicate, late and out-of-order messages the interface must survive

Resilience cases decide whether the interface is safe on a bad day. The pass rule for every one of them is the same: one physical event produces one posting, whatever the network does. Run these with the integration engineer present, because most need a message to be replayed, delayed or blocked deliberately.

• MSG-01 Exact duplicate: resend a ship confirm with the same message ID. Expected: second copy acknowledged and discarded; one goods issue.
• MSG-02 Retry with a new message ID: middleware resends the same business event under a new ID. Expected: duplicate detected by business key (order, shipment and line), not by message ID alone.
• MSG-03 Out-of-order arrival: deliver a ship confirm before the pick confirm, or an adjustment before the receipt it corrects. Expected: held and processed in sequence, or rejected with a retry; never posted against negative stock.
• MSG-04 ERP unavailable: stop the ERP endpoint for 30 minutes during outbound. Expected: messages queue, then replay in order once it returns, with zero loss.
• MSG-05 Malformed payload: Expected: dead-letter queue entry and an alert to the support rota within the agreed time; nothing partially posted.
• MSG-06 Partial batch failure: a batch of 50 lines where line 37 fails. Expected: either all 50 roll back or 49 post and line 37 waits; the rule is written down beforehand.

The trace below is from a UAT day where MSG-02 was skipped because "the middleware handles retries". It shows how a second posting appears without anyone sending anything twice on purpose.

1. 09:12:04 ship confirm sent: WMS sends shipment SHP-20418 for order SO-77310, 25 units, message ID M-90021. ERP returns no acknowledgment because of a gateway timeout.
2. 09:12:34 automatic retry: middleware resends the same payload as message ID M-90022. The ERP's duplicate check keys on message ID only, so it accepts it.
3. 09:12:35 second goods issue: ERP posts a second goods issue of 25 units against SO-77310 at a standard cost of $62.00, doubling cost of goods sold for the line to $3,100.
4. 09:40:10 invoice run: the billing job invoices 50 units to the customer; stock for the item shows minus 25 in the ERP while the WMS shows the correct balance.
5. 14:05:00 reconciliation catches it: the cycle reconciliation reports a 25-unit unexplained variance. Root cause: duplicate detection on message ID instead of shipment and line key. Logged as severity 1.

Reconciliation query, evidence pack, severity and defect cost

Run a quantity reconciliation after every UAT cycle, in base units, with messages still in flight counted separately. Anything left after that is a defect until someone explains it. The query below is written against two snapshot tables and a queue table; rename the objects to match your landing area, but keep the logic and the sign convention.

-- ERP vs WMS quantity reconciliation for one UAT cycle, in base units (EA)
-- in_flight.qty_signed: + for WMS events not yet posted in ERP (receipts),
--                       - for WMS issues not yet posted in ERP (shipments, losses)
WITH erp AS (
  SELECT item_id, site_id, SUM(qty_base) AS erp_qty
  FROM erp_stock_snapshot
  WHERE cycle_id = :cycle_id
  GROUP BY item_id, site_id
),
wms AS (
  SELECT s.item_id, s.site_id, SUM(s.qty * u.factor_to_base) AS wms_qty
  FROM wms_stock_snapshot s
  JOIN uom_conversion u ON u.item_id = s.item_id AND u.uom_code = s.uom_code
  WHERE s.cycle_id = :cycle_id
  GROUP BY s.item_id, s.site_id
),
in_flight AS (
  SELECT item_id, site_id, SUM(qty_signed) AS q
  FROM integration_queue
  WHERE cycle_id = :cycle_id AND state IN ('PENDING', 'RETRY')
  GROUP BY item_id, site_id
)
SELECT COALESCE(w.item_id, e.item_id) AS item_id,
       COALESCE(w.site_id, e.site_id) AS site_id,
       COALESCE(e.erp_qty, 0) AS erp_qty,
       COALESCE(w.wms_qty, 0) AS wms_qty,
       COALESCE(f.q, 0) AS in_flight_qty,
       COALESCE(w.wms_qty, 0) - COALESCE(e.erp_qty, 0) - COALESCE(f.q, 0) AS unexplained_qty
FROM erp e
FULL OUTER JOIN wms w ON w.item_id = e.item_id AND w.site_id = e.site_id
LEFT JOIN in_flight f ON f.item_id = COALESCE(w.item_id, e.item_id)
                     AND f.site_id = COALESCE(w.site_id, e.site_id)
WHERE COALESCE(w.wms_qty, 0) - COALESCE(e.erp_qty, 0) - COALESCE(f.q, 0) <> 0
ORDER BY ABS(COALESCE(w.wms_qty, 0) - COALESCE(e.erp_qty, 0) - COALESCE(f.q, 0)) DESC;
-- Pass rule: zero rows returned. Any row is a defect until explained and signed.

Keep an evidence pack per case: the input (order, notice or count sheet), the outbound and inbound message IDs with timestamps, screenshots or exports of the ERP document created, the reconciliation output for the cycle and the tester's initials with date. PCAOB AS 2810 lists the inability to produce evidence of program change testing for current-year system changes as a matter that can affect an auditor's fraud-risk assessment, so the pack is not paperwork for its own sake.

• Severity 1, blocks go-live: wrong quantity, value, status or period posted; a duplicate posting; a statutory field lost or altered; a rejection that should have happened but did not.
• Severity 2, needs a dated fix: correct posting but a missing alert, an unclear error text or a manual step that has a written workaround.
• Severity 3, can follow go-live: log wording, report layout or performance within the agreed limit.

A cycle reconciliation between ERP stock and WMS stock in base units passes only at zero unexplained rows after in-flight messages are netted. PCAOB AS 2810 paragraph C1 treats missing evidence of program change testing as a fraud-risk matter, so each failing row needs a logged defect and a named signer.

Put a value on each severity-1 defect so the steering group understands why the script cannot be shortened. The figures below are illustrative, but the arithmetic is the same for any item. The US rows show the ledger effect; the Indian rows add a compliance effect, because the rupee value of a consignment decides whether an e-way bill is needed.

The Indian outbound row is the one that surprises steering groups. The stock is right, the truck leaves and the error only appears if an officer checks the vehicle. That is why OB-06 asks testers to compare the invoice value and statutory fields in the ERP billing document with the source order, not only the quantity in the WMS.

Which checks stay fixed rules and where software helps a tester

Postings and rejections must come from fixed, tested rules in the ERP or the integration layer. Software, including AI tools, can speed up the tester's work around those rules: drafting defect tickets, clustering variances, proposing edge-case data. A person still decides whether a case passed. Write that split into the script so nobody automates a sign-off by accident.

Cutover rehearsal and the gates for go-live sign-off

Cutover cases test the move from old balances to new ones. Run at least one full rehearsal with production-sized data, and treat its reconciliation exactly like a UAT cycle. The go-live decision then rests on numbers already seen, not on a promise that the real weekend will go better. Our separate guide to WMS migration cutover reconciliation goes deeper on freeze windows and balance loads.

• CUT-01 Opening balances: load on-hand by item, lot and location. Expected: quantity reconciliation returns zero rows; value differs only by rounding.
• CUT-02 Open inbound: purchase orders and notices in transit at freeze. Expected: each still receivable once in the new flow, never twice.
• CUT-03 Released outbound: orders released to the old WMS but not shipped. Expected: one owner after cutover, and a ship confirm accepted only from that owner.
• CUT-04 Rollback: reverse the cutover in rehearsal. Expected: old system balances restored and reconciled within the rollback window.

An ERP and WMS go-live gate for an Indian entity should include a statutory field check, because CGST Rule 138(1) requires e-way bill information for consignments above ₹50,000 and the NIC e-invoice hash depends on GSTIN, document number, type and year. One altered character in the invoice number fails that check.

Running the catalogue in three cycles and closing it out

Run the catalogue three times: a first cycle to find mapping defects, a second after fixes to prove them, and a production-sized rehearsal that includes cutover. Reconcile after each one. Reuse the same case IDs across cycles so the defect register shows which cases failed, which recovered and which never ran, and so the auditor can trace one case from input to signed result.

Message-level detail for the X12 path, such as the 856 notice and the 945 confirmation, sits in our EDI 856, 940, 945 and 214 integration guide, and item and pack hierarchy rules sit in the SKU, pack hierarchy and unit-of-measure guide. More warehouse and transport topics are on the logistics and supply chain hub.

• Cycle one goal: every case executed once, with defects logged by severity and owner.
• Cycle two goal: all severity-1 fixes retested, with zero unexplained reconciliation rows.
• Rehearsal goal: production-sized data, cutover cases included, signed exit gates.

If you want a second pair of eyes on the catalogue, or help turning it into an evaluation script for a new WMS or integration partner, you can send us your requirements. We will reply with the cases we would add for your item master, message volumes and markets before any build work starts.