Accounting integration acceptance tests: what to prove in the sandbox

An accounting integration passes acceptance when it produces the agreed records, totals, dates, and evidence under ordinary and exceptional conditions. A successful connection or green sync status proves much less. Finance should define the expected result for each test, and the implementation team should show both the source record and the resulting ledger record.

Create a small test pack using fictional customers, suppliers, invoices, and payment references. For each case, record the starting conditions, action, expected accounts and amounts, permitted timing, and evidence required. Have the accountant approve the accounting treatment before testing, so a disagreement about policy is not mistaken for a software defect.

Keep the test data recognizable. A distinctive reference lets reviewers locate the same case in the source, connector, and ledger without relying on screenshots with similar customer names.

Intuit distinguishes development credentials used for QuickBooks Online sandboxes from production credentials used for live companies. Its sandbox documentation also identifies limits, including unsupported live bank connections. Xero's developer FAQ describes using a demo company and API Explorer to make calls against demonstration data. These environments support useful checks, but they are not interchangeable with the eventual production arrangement.

Confirm the ledger edition, region, enabled features, permissions, and connector configuration represented in the test. Record any difference from the proposed live environment. A feature available in the demonstration may require a different subscription or setup when the integration goes live.

Use the providers' supported test records and payment methods. Do not route real customer communications or money through a test case unintentionally. Assign separate test destinations for notifications and make the environment visible to anyone operating it. The purpose is to prove the workflow while keeping the test population identifiable.

Take a hypothetical $1,200 customer invoice with no tax, discount, or currency conversion. Under an approved receivables design, it should create one $1,200 open item with the correct customer, entity, date, and reference. The accountant should specify the offset account, since the invoice alone does not determine whether the amount is immediately recognized as revenue.

Now record a $1,200 customer payment from which the processor deducts an illustrative $30 fee, leaving $1,170 for payout. The test should clear the correct receivable, preserve the fee separately, and connect the resulting clearing balance to the eventual bank receipt. It should not leave a $30 unpaid customer balance simply because the payout was net of fees.

Repeat the payment notification or import. The ledger should still contain one accepted payment. Then issue a partial credit and refund using a separate test case, preserving the connection to the original invoice. Compare both the individual records and the relevant account totals after each step.

A useful pack includes events that should stop or require review. Define the expected response before the vendor runs them. A rejected transaction with a clear reason can be a successful test result.

Save the source identifiers, connector run details, accounting record references, reconciliation totals, and reviewer result for each case. Screenshots can explain an issue, but they should not be the only way to reproduce it. Record the configuration and mapping version used so a later change can be traced to the result it affects.

Classify unresolved findings by their financial effect. Missing records, duplicate postings, wrong entities, unexplained totals, and uncontrolled closed-period changes need resolution before the affected flow is accepted. A cosmetic display issue may have a different priority. Agree the distinction with finance rather than letting the vendor decide it from technical severity alone.

Document what the sandbox could not prove, such as actual bank settlement, production-only permissions, or the final provider account configuration. Give each remaining item an owner and a specific production verification step. Do not label an untested behavior as passed merely because a related test succeeded.

Begin live processing with a defined population and review its first complete reconciliation. Keep the prior process available where appropriate until the new route is accepted, with a clear boundary preventing both from posting the same records. The handover is complete when the operating team can resolve exceptions and demonstrate the accounting result without depending on the original implementer.