A module exporting pushInvoice, syncInvoicePaymentStatus, resolveInvoiceIdsForEntity, findOrgIdsByRealmId, ensureProjectForJob and ensureCustomer. The vendor-specific modules become provider-internal, and the rule is greppable: outside the providers directory, a direct vendor-module import is a boundary violation.
Also called: swap accounting package · Xero one day · AccountingPort
- 1Routes import the neutral names from the boundary module.
- 2The boundary re-exports the vendor implementations under those names.
- 3A future provider implements the same exports behind a registry binding.
The module explains the choice to establish a boundary rather than refactor working code: 'QBO was already the best-contained integration... so this pass establishes the MODULE BOUNDARY rather than re-shaping working logic: every route that talks accounting imports from HERE, and the quickbooks* libs become provider-internal. Enforcement is greppable.' The same pattern is applied to the estimator and the platform-Stripe flow.
- Vendor-specific imports scattered across routes would make a second provider a rewrite.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →