Extending a Zuper–NetSuite Integration into Bidirectional Invoice & Inventory Sync

Introduction

A field service organization running Zuper for job management and NetSuite as its accounting system already had a scheduled, one-way invoice transfer moving completed jobs into NetSuite. The next step was to extend that foundation into a fully bidirectional integration, so that everything happening to an invoice or a part after the first transfer — amendments, cancellations, credit notes, payments and stock movements — stayed aligned across both platforms. This case study covers that extended scope.

Problem Statement

The core sync moved invoices from Zuper into NetSuite, but nothing after that initial transfer was connected. When an invoice was amended or cancelled in Zuper, when a credit note was raised, or when a customer payment was applied in NetSuite, the other system never heard about it. Parts availability lived only in NetSuite, so field technicians had no reliable view of stock. Finance was left reconciling changes by hand, and every manual touch carried the risk of a duplicate posting, a mismatched status or a write into an already-closed accounting period.

Solution

We designed an extended, event-driven integration built on the link established at the first transfer — the NetSuite internal ID stored on the Zuper invoice and the invoice number custom field stored on the NetSuite record. Every flow carries an origin flag so an update written by the integration never triggers the opposite flow, and any operation that would touch a closed period is held for finance rather than forced through.

How It Works

Every extended flow builds on the same shared link and a common set of guardrails established at initial transfer:

1. A change event — an edit, cancellation, credit note, payment or stock movement — is received and the linked record is located using the stored identifier.
2. The target record is checked for eligibility before anything is written, so paid invoices and closed periods are never silently overwritten.
3. Eligible changes are applied in place; ineligible ones raise an exception naming the record and the blocking condition.
4. An origin flag is set on the write so the receiving system does not fire the opposite flow, preventing circular updates.
5. Every action is written to a shared run log, tagged with the capability reference, so each flow is traceable rather than failing silently.

Invoice updates are a good example of the eligibility model in action: an open, unpaid invoice in an open period is updated in place, while a partially or fully paid invoice, a closed period or an already-voided invoice is held and reported for finance review instead of being forced through.

Implementation

Implementation began by mapping the Zuper invoicing and approval workflow against NetSuite's contact, item, tax, subsidiary and period structures, so every field had a clear source and destination before development started. Duplicate checks, status mapping and loop prevention were built as configurable rules rather than fixed values, which is what lets new job categories and status changes be absorbed later without rework.

Payment information was scoped to flow one way only — from NetSuite into Zuper — since payments are never created in NetSuite by the integration itself. For inventory, warehouse, van-stock and location codes are mapped one-to-one before the flow is enabled, NetSuite stays the system of record for quantity and valuation, and parts consumption posts at job completion rather than at assignment so unused parts are never deducted. The extended flows are switched on only once the core sync is live and stable in production.

Results & Achievements

The extended integration turned a one-way feed into a connected, two-way financial and inventory picture across both systems: