System Integration
Sequence Map
The full dependency chain for a post-acquisition e-commerce integration across ERP, tax compliance, and payment processing. Break any step to see what fails downstream. Every constraint in this architecture exists because the alternative was tested ... by accident or by assumption.
Download Blank Template ↓Three Systems
One Sequence
NetSuite
System of Record
+ Transaction Hub
+ Transaction Hub
Single source of truth for all invoice, order, and financial data. Every other system reads from or writes back to NetSuite. Nothing bypasses it.
Must not: calculate tax, process payments directly, or allow parallel config
Tax Engine
Tax Calculation
+ Compliance
+ Compliance
Calculates tax on invoices, writes amounts back to the ERP, and handles returns reporting. Activated only after invoice creation, never before.
Must not: process payments, modify invoice records, or operate independently
Payment Processor
Payment Collection
+ Posting
+ Posting
Consumes finalized invoices (after tax) and posts payment records back to the ERP. Operates only inside the ERP's native record structure.
Must not: calculate tax, override amounts, or bypass the ERP
Break a Step
Watch What Falls
This is the transaction lifecycle. Each step depends on the one before it. Click "Break" on any step to see what fails downstream. The cascade is not theoretical. These are the failure modes the governance model was built to prevent.
How to read this: Green steps are healthy. Click "Break" to skip or corrupt a step. Downstream steps turn yellow (damaged) and a cascade panel shows the domino effect. Click "Break" again to restore. Break multiple steps to see compound failure.
01
ERP
Invoice Created in ERP
Order enters the system. Invoice record created with line items, quantities, and pre-tax amounts.
If This Step Fails
↓
Tax Engine
Nothing to calculate against. Tax engine receives no invoice data. Sits idle or throws errors.
↓
Payment Processor
No invoice to collect on. Payment processor has no record to reference ... it cannot even start.
↓
Accounts Receivable
No payment posted. No invoice to reconcile. AR has a ghost transaction ... revenue recognized in one system, invisible in another.
↓
Terminal Consequence
The entire transaction lifecycle is dead. No invoice means no tax, no payment, no reconciliation. Every downstream system is waiting for a record that does not exist.
Cost: Total system halt per transaction. Manual intervention required for every order.
02
Tax
Tax Engine Calculates
Tax engine reads the invoice, calculates jurisdiction-specific tax, and returns the amount.
If This Step Is Skipped
↓
ERP Invoice
Invoice remains pre-tax. Total is incomplete but looks valid ... the most dangerous state because nothing flags it as wrong.
↓
Payment Processor
Collects on the pre-tax amount. Customer is undercharged on every transaction. The gap compounds with volume.
↓
Compliance
Tax engine has no transaction data for reporting. Filing obligations go unmet. Audit exposure accumulates silently.
↓
Terminal Consequence
Revenue leakage + compliance exposure on every transaction. The system appears functional. Customers are being served. But the company is losing money and accumulating tax liability on every single order.
Cost: Revenue leakage per transaction + compounding compliance liability. This was the live state when the project started.
03
ERP
Tax Written Back to ERP
Tax amount written back to the invoice record. Invoice is now tax-complete and ready for payment.
If the Write-Back Fails
↓
ERP Record
Tax was calculated but never recorded. The ERP thinks the invoice is pre-tax. The tax engine thinks it is done. Two systems disagree on the same transaction.
↓
Payment Processor
Same problem as skipping Step 2 ... collects on a pre-tax amount. But now tax was calculated and lost, which is harder to diagnose.
↓
Terminal Consequence
System state divergence. The tax engine's records and the ERP's records no longer match. Reconciliation becomes forensic work, not routine accounting.
Cost: Silent data divergence. Harder to detect than a total failure because both systems appear operational.
04
ERP
Invoice Finalized
Invoice is complete: line items + tax + total. Locked as a committal financial record. Ready for payment.
If Finalization Is Skipped
↓
Payment Processor
Collects on a draft invoice. Amounts can still change after payment. Customer is charged for a moving target.
↓
Accounts Receivable
Payment posted against an unfrozen record. If the invoice is later modified, the payment no longer matches the invoice. Manual adjustment required.
↓
Terminal Consequence
Financial record integrity breaks. Payments and invoices drift apart. Every adjustment creates a new reconciliation problem. The accounting team stops trusting the system.
Cost: AR trust erosion. Manual reconciliation per transaction. System credibility loss.
05
Pay
Payment Processor Collects
Reads the finalized invoice. Collects payment from the customer based on the locked total.
If Payment Collection Fails
↓
ERP
Invoice exists and is finalized but no payment record is created. The invoice ages. AR sees an unpaid balance.
↓
Customer
Depending on failure mode: customer is either double-charged on retry or never charged at all. Both outcomes create support and trust problems.
↓
Terminal Consequence
Revenue collection stops. The upstream work (invoice, tax, finalization) was all correct but valueless without payment. Orders ship, money does not arrive.
Cost: Revenue gap per failed collection. Customer relationship damage. Manual dunning required.
06
ERP
Payment Posted to ERP
Payment record written back to the ERP. Invoice marked paid. AR updated. Loop nearly closed.
If the Post-Back Fails
↓
Accounts Receivable
Customer was charged. Money was collected. But the ERP does not know. Invoice still shows as unpaid. AR sends collection notices for debt that does not exist.
↓
Tax Reporting
Tax engine receives incomplete transaction data. Payment details are missing. Compliance reporting is inaccurate.
↓
Terminal Consequence
Orphaned payments. Money exists in the payment processor but is invisible to the ERP. This is the reconciliation nightmare that makes finance teams demand manual oversight of every transaction.
Cost: Orphaned payment records. False collection actions. Finance trust collapse.
07
Tax
Tax Engine Receives Transaction Data
Completed transaction data flows back to the tax engine for compliance reporting and returns processing.
If Reporting Data Never Arrives
↓
Tax Compliance
Tax was calculated and collected but the tax engine has no record of the completed transaction. Its filing data is incomplete.
↓
Audit Exposure
If audited, the company cannot demonstrate that tax collected matches tax filed. The gap between "collected" and "reported" becomes a liability.
↓
Terminal Consequence
Compliance liability with no visibility. The operational system works. Customers are served. Revenue is collected. But the compliance record has holes that grow with every transaction.
Cost: Invisible compliance debt. Audit risk. Potential penalties that scale with transaction volume.
Every constraint in this architecture exists because the failure it prevents was either observed or narrowly avoided. The sequence is not a preference. It is a structural requirement. Breaking any step does not just affect that step ... it damages every system downstream. The over-thinking is the product.