Here is a pattern we have seen in many forms. A company receives goods against a purchase order. Receipt accounting posts an accrual for the goods received but not yet invoiced. When the supplier invoice arrives and is matched to the receipt, the accrual should clear. For a while, it does.

Then something changes on one side of the flow. Invoices start arriving through a new capture integration that references purchase order lines in a slightly different way. Or a quarterly update adjusts matching behavior. Or the warehouse system begins sending receipts with a different unit of measure. Invoices still get entered and paid. But they no longer match the receipt that created the accrual, and the accrual stays open. Nobody notices until reconciliation, when the balance has grown for weeks.

Every test passed

The frustrating part is that testing was done. The receiving team tested receipts. The payables team tested invoice entry and payment. The finance team tested journal posting. Each set of tests passed, because each module worked on its own.

Module tests pass, the chain failsP2P into R2R
Purchaseorder Goodsreceipt Accrualposted Invoicevia integration Match toreceipt Accrualclears PO line reference changed Each module tested alone Passes Passes Passes Passes Passes Passes One chain test across every handoff Order, receive, accrue, invoice, matchFails: accrualstill open
Illustrative view

Only a test that followed the record from purchase order to cleared accrual would have caught it, and checked the accounting outcome at the end rather than stopping when the invoice was paid.

Why handoffs go untested

  • Teams are organized by module. Each team tests what it owns, and the space between modules belongs to no one
  • Integrations are tested for format. A message that arrives with valid structure passes, even if a key reference is wrong
  • Outcomes appear later. The accrual not clearing shows up at period-end, long after the test that created the invoice has finished
  • Environments are incomplete. The warehouse or capture system is often stubbed in test, so the real handoff never runs

Kinds of handoff to look for

Handoffs come in several shapes. Most business process chains contain all of them.

  • Module to module. Receiving to payables to the general ledger, within one platform
  • System to system. CRM order into ERP, HCM changes into a payroll provider, payment files to a bank
  • Period to period. An accrual posted this month that should reverse or clear next month
  • Person to person. An approval that routes work from one role to another
  1. P2PProcure to pay
  2. R2RRecord to report
  3. O2COrder to cash
  4. H2RHire to retire
  5. T2PTime to pay

What to check at each handoff

A chain test is only as good as its checks. Running a record through every step and confirming that each screen loads proves little. At every handoff, check that:

  • The record arrives on the other side
  • Key references are carried correctly, such as the purchase order line, quantity, amount, currency and cost center
  • The downstream status changes as expected, for example from received to matched
  • The accounting outcome is right, including accruals created, reversed or cleared
  • The timing holds, especially across a period boundary

The fourth check is the one that would have caught the accrual. It is also the one most often left out, because it sits in a different module from the step that caused the problem.

Check the ledger, not just the screen

Many handoff outcomes are not visible on any screen a tester would open. An accrual that failed to clear does not raise an error. It simply remains in a balance. The most reliable way to catch it is a data check at the end of the chain: query the accrual lines for the receipt the test created and confirm they are cleared, with the amounts the invoice should have relieved.

The same applies elsewhere. A payroll handoff is best confirmed by the pay result, not the confirmation message. An order handoff into ERP is best confirmed by the sales order and its pricing, not by the CRM status that says "sent".

Make chains a standing part of testing

  • List the handoffs in each business process chain and give each one an owner
  • Write an expected result for every handoff, not just for the end of the chain
  • Run chain tests early in every release window, right after the blockers
  • Re-run the chain whenever either side of a handoff changes, including vendor updates and integration releases
  • Include a period-boundary scenario for any chain that posts accruals

How Qventis One helps

The App Model in Qventis One holds each business process chain as ordered steps with every handoff between modules and systems, and an expected result at each one. The Qventis Engine runs chains end to end across web, desktop, API and data checks in the second execution wave, and step traceability means a vendor change or integration change on either side of a handoff brings the whole chain into the test delta. Quality View shows exactly which handoff failed. Book a demo to see a chain tested across every handoff.