Technical Integration Guide · 2026
NetSuite to Zycus. What the integration actually involves.
NetSuite gives you the financial backbone: vendor records, purchase orders, vendor bills, payments. Zycus adds the source-to-pay layer in front of it. This guide lays out the architecture plainly: what connects, across which NetSuite API surface, what your team owns, and what Zycus owns.
Request the integration design workshop →Request the integration guide
NetSuite customers across 219 countries
SOAP, REST, RESTlets, SuiteQL. One ERP, four front doors
No new token-based-auth integrations after this release
Scheduled removal of legacy SuiteTalk SOAP
Sources: Oracle NetSuite (customer count, 2025); NetSuite SuiteTalk REST and SuiteQL documentation; NetSuite release notes (SOAP / TBA deprecation timeline). SOAP web services are removed in 2028.2, and no new token-based-auth integrations can be created after 2027.1.
Why this matters now
No migration clock.
The clock is on your integration surface.
NetSuite is cloud-native, so there is no legacy-to-cloud deadline. But the way you connect to NetSuite is changing underneath you, and native procurement runs out of room as you grow. Both are reasons the integration conversation is live today.
The surface line
SOAP and TBA are on the way out. No new SOAP endpoints ship from the 2026.1 release, with removal scheduled for 2028.2. No new token-based-auth integrations after 2027.1. An integration still built on SuiteTalk SOAP and TBA is technical debt the day it goes live.
The growth line
You outgrow native procurement. NetSuite handles POs, receipts and vendor bills well. It does not carry multi-round sourcing events, guided intake, supplier KYC and risk scoring, eInvoicing, or AI spend classification. As spend and supplier count scale, that gap becomes the bottleneck.
The subsidiary line
OneWorld multiplies the data. Add subsidiaries and the same vendor can fragment across them, gated by role-level subsidiary permissions. Without a golden-record layer, every new subsidiary compounds duplication and sync risk.
Architecture
The Zycus and NetSuite connection, laid out plainly
Four nodes. Two directions. The twist that is specific to NetSuite: there is no single API. Zycus iSaaS orchestrates the right surface for each operation so your team does not have to.
Your ERP
NetSuite
OneWorld · SuiteCloud. Vendors, subsidiaries, receipts, bills, payments.
Optional
Middleware
Celigo · Boomi · Workato. Transport layer, optional not required.
Mapping brain
Zycus iSaaS
API gateway · surface orchestration · GenAI Mapper. Transformation and monitoring.
S2P apps
Zycus S2P
Intake → Sourcing → P2P → eInvoice. Ends at PO and vendor bill.
One ERP, four front doors. iSaaS picks the right one per operation.
SuiteTalk REST
Record writes: create and update vendors, POs, vendor bills. JSON, OAuth 2.0.
SupportedSuiteQL
Reads with JOINs: spend extracts, status feedback, bulk pulls.
SupportedRESTlet
Gaps REST cannot cover: PO PDF, dynamic field metadata. SuiteScript.
SupportedSuiteTalk SOAP
Legacy only, where unavoidable. Removal scheduled 2028.2.
DeprecatingYour existing iPaaS provides the transport tunnel. Zycus iSaaS owns all mapping logic and surface selection. The iPaaS never needs to understand NetSuite vendor or transaction semantics.
No iPaaS. Zycus iSaaS connects directly on SuiteTalk REST for writes, SuiteQL for reads, and a deployed RESTlet for gaps, all on OAuth 2.0. Fewer moving parts, the modern supported surface set from day one.
Integration touchpoints
Every module. Every NetSuite record. Every direction.
| Module | Direction | What moves | NetSuite record · surface |
|---|---|---|---|
| Vendor Master | ↓ Inbound | NetSuite vendor record to Zycus supplier golden record. Subsidiary carried as an attribute (OneWorld). | Vendor · entity · subsidiary · SuiteQL read |
| User Master / SSO | ↓ Inbound | User identity sync and single sign-on. Approval routing optionally from NetSuite roles or SuiteApprovals. | Employee · SAML 2.0 · Entra ID · Okta |
| Org Structure | ↓ Inbound | Subsidiaries, departments, classes, locations, GL accounts for routing, coding, validation. | Subsidiary · Department · Class · Location · Account |
| Intake Management | Internal | Guided intake, smart routing, workflow approval. Zycus-internal only, no NetSuite integration at this layer. | No NetSuite touchpoint |
| Sourcing | ↑ Outbound | New supplier from a sourcing event pushed to the NetSuite vendor record. Sync keeps both in step. | Vendor create / update · SuiteTalk REST |
| Contracting | ↑ Outbound | Executed contracts pushed to NetSuite as blanket purchase orders or linked records for release. | Blanket PO · custom record · REST |
| Supplier & Risk Mgmt | ⇄ Bi-directional | Supplier onboarding (KYC, risk scores) and the NetSuite vendor record stay synchronised. Risk flags update Zycus. | Vendor · custom fields · REST + SuiteQL |
| eProcurement / P2P ★ | ↑ Outbound | Requisition to approval to PO creation, the last Zycus step. Receipt, match and payment stay in NetSuite. | Purchase Order · SuiteTalk REST · Item Receipt |
| eInvoice, Bill Post NEW | ↑ Outbound | Invoice validated in Zycus, 3-way matched, then posted to NetSuite pre-validated as a vendor bill. | Vendor Bill · Bill Credit · REST |
| eInvoice, Payment Status NEW | ↓ Inbound | After bill payment, payment confirmation and date feed back into the Zycus Supplier Network. Suppliers see lifecycle. | Bill Payment · SuiteQL read |
| Spend Analysis | ↓ Inbound | AP spend, GL actuals, subsidiary and department feeds pulled into Zycus for AI UNSPSC classification and analytics. | SuiteAnalytics · SuiteQL · GL |
| PO Status Feedback | ↓ Inbound | Item receipt, bill status, payment completion fed back so suppliers see PO lifecycle. | Item Receipt · Vendor Bill · SuiteQL |
★ PO creation is the last Zycus step. Item receipt, 3-way match, vendor bill and payment are handled in NetSuite. NetSuite stays the system of record throughout.
Integration models
Two models. The difference is who owns the mapping.
Both run on the same Zycus iSaaS gateway. The only question is whether Zycus or your Celigo / SuiteScript team builds and maintains the field-mapping logic and any RESTlet.
Model A
Integration as a Service (iSaaS-led)
Zycus builds and maintains the mapping logic and any RESTlet inside iSaaS. Works with or without existing middleware.
- Mapping logic
- Zycus iSaaS, our responsibility and SLA
- RESTlet (for gaps)
- Zycus deploys and maintains it
- Your team's effort
- Integration role and permissions, UAT
- AI Mapper
- Live field-mapping session, one session, signed off
- Best when
- Speed matters or SuiteScript bandwidth is scarce
Model B
Customer-Owned Integration
Your Celigo, Boomi, or SuiteScript team builds and maintains the mapping logic and any RESTlet.
- Mapping logic
- Your Celigo / Boomi / SuiteScript team
- iSaaS role
- API gateway and error monitoring only
- Your team's effort
- Majority, including any RESTlet
- AI Mapper
- Available as reference, Zycus does not run it
- Best when
- Internal ownership is a hard governance requirement
Effort split, Model A (iSaaS-led) · illustrative, confirmed at design workshop
Zycus: mapping, surface orchestration, RESTlet, AI session, monitoring.
Your team: integration role and subsidiary permissions, connectivity, payload validation, UAT.
Model B inverts this ratio.
The differentiator
Where integration projects lose weeks, and why we don't
A NetSuite vendor or transaction is not a flat record. It has body fields, sublist lines, subrecords, internal-ID references, and a different shape depending on whether you read it through REST, SuiteQL, or a RESTlet. Competitors map that in offline spreadsheet exchanges over weeks. We do it live, in one session, with AI confidence scoring.
Live mapping session
Load your NetSuite source payload and the Zycus target schema. The AI maps field-to-field on screen, in the room, internal-ID resolution included. What used to take weeks takes an afternoon.
NetSuite-native intelligence
The mapper knows the Vendor, Purchase Order and Vendor Bill records, the SuiteQL schema, sublist structures, and internal-ID linkage from real NetSuite integration experience embedded in the model.
Confidence scoring
Each mapping carries a confidence score. Edge cases are flagged, not silently wrong. Logic is described in plain English for business and technical reviewers.
Load schemas
Upload NetSuite source (REST schema, SuiteQL result, JSON) and the Zycus target schema.
AI auto-maps
GenAI generates field-to-field mappings with plain-English transformation rules.
Review + adjust
Review against confidence scores. Adjust edge cases and internal-ID lookups. Lock and sign off.
Live transform
Run against a real NetSuite sandbox payload. See the Zycus output. Validate before SIT.
Master data design
The vendor and subsidiary problem, and the correct pattern
In OneWorld, the same vendor can be scoped or duplicated across subsidiaries, and the integration role's subsidiary permissions decide what is even visible. Designed wrong, you inherit duplicates and blind spots. Designed right, Zycus is the layer that cleans it up.
In NetSuite
- OneWorld: a vendor can be shared across subsidiaries or held per subsidiary, each with its own internal ID.
- The integration role's subsidiary restrictions gate which records the connection can even see.
- Currency, tax registration and payment terms can differ per subsidiary on the same entity.
- Risk: vendors duplicated per subsidiary, role-scoped blind spots, sync errors if not designed up front.
In Zycus
- One supplier equals one golden record, deduplicated on a primary key you define.
- Subsidiaries carried as attributes, not separate records.
- Per-subsidiary currency, tax ID and terms held as sub-records, same entity, different scope.
- Sync engine writes back the correct per-subsidiary vendor record automatically.
- Dynamic workflow per subsidiary, region, or risk tier, not hardcoded to NetSuite roles.
Worked example: one supplier across three subsidiaries
Subsidiaries carried as org attributes. Auto-sync, no manual translation.
| Subsidiary | Currency | Payment terms | Local tax ID | Status |
|---|---|---|---|---|
| US Parent | USD | NET_30 | 12-3456789 | ACTIVE |
| UK Sub | GBP | NET_45 | GB-987654321 | ACTIVE |
| DE Sub | EUR | NET_60 | DE-123456789 | INACTIVE |
golden record in Zycus
Three subsidiaries, one deduplicated supplier. The sync engine writes back the correct per-subsidiary vendor record, no manual translation.
Scope boundary
What the standard offer covers, and what it doesn't
Scope ambiguity is what turns a 6-month integration into a 14-month one. This is the standard boundary. Every item is confirmed or classified before design begins.
Included in the standard offer
- ✓Integration-as-a-Service via iSaaS (REST plus SuiteQL plus RESTlet orchestration, OAuth 2.0)
- ✓Onsite design workshops and solution configuration for agreed scope
- ✓TPRM connectors via App Extend (EcoVadis, D&B, Moody's, Trustpair)
- ✓eInvoice integration, outbound posting to vendor bill and payment-status feed
- ✓Data migration templates (CSV / REST loads) and load support
- ✓Go-Value workshop(s), mandatory pre-go-live
- ✓Train-the-Trainer enablement via Zycus University
- ✓UAT support and go-live hypercare (4 weeks pilot, 2 weeks per wave)
Treated as a change item
- △Modules or subsidiaries beyond the signed scope
- △Integration touchpoints not in the agreed inventory
- △Customer-owned build effort in iPaaS or SuiteScript (if Model B)
- △Direct materials or bespoke custom development
- △Third-party TPRM licences, customer-owned
- △End-user training beyond Train-the-Trainer
- △Change management on the customer's side
- △NetSuite-side custom SuiteScript and SuiteApprovals reconfiguration
Field intelligence · real conversations
Integration objections NetSuite teams raise, and direct answers
"NetSuite already has purchase orders and vendor bills. Why add Zycus?"
Native NetSuite owns the transaction backbone, PO, item receipt, vendor bill, payment, and keeps it. It does not carry guided intake, multi-round sourcing events, supplier KYC and risk scoring, eInvoicing, or AI spend classification. Zycus sits in front for source-to-contract and intake-to-PO. NetSuite stays the financial system of record. PO creation is the hand-off line.
"Our current integration runs on SuiteTalk SOAP and token-based auth. Is that a problem?"
It is on a deprecation path: no new SOAP endpoints from the 2026.1 release, removal scheduled for 2028.2, and no new TBA integrations after 2027.1. Zycus iSaaS connects on SuiteTalk REST plus SuiteQL with OAuth 2.0, the supported surfaces, so the integration you stand up now is not technical debt on arrival.
"We run OneWorld with 20+ subsidiaries. Won't Zycus duplicate every vendor?"
No. One golden record, deduplicated on a key you define, subsidiaries carried as attributes, and the sync engine writes back the correct per-subsidiary vendor record. The integration role's subsidiary permissions are confirmed in the master-data design session so nothing is silently invisible.
"Some of what we need just isn't in NetSuite's REST API."
True, a few things, like generating a PO PDF or reading dynamic field metadata, need a RESTlet. Under Model A, Zycus writes, deploys and maintains that SuiteScript RESTlet as part of iSaaS. You do not author or own NetSuite scripts. Under Model B, your team owns it.
"Who owns the integration role and its permissions?"
You do. It is created in your account against a role you control, scoped to the subsidiaries and records in the agreed inventory. The most common production failure is a token created against the wrong role. We confirm role, permissions and subsidiary scope at the design workshop, not after go-live.
"Mixing goods and services on a PO causes receipt and bill-match failures."
Zycus enforces category segregation at the requisition stage, before the PO is created. Business rules prevent a cart mixing goods and service lines, so the user corrects it at point of entry. What reaches NetSuite is always a cleanly-typed purchase order. The rules are configurable and set in the design workshop.
"Who owns what after PO creation? We don't want Zycus in our AP."
PO creation is the last Zycus step, the purchase order posts via SuiteTalk REST. After that, item receipt, 3-way match, vendor bill and bill payment are all NetSuite. For eInvoice, Zycus 3-way matches then posts a pre-validated vendor bill. What flows back after payment is payment status only, a read-only SuiteQL feed. NetSuite stays the system of record.
"We have heavy SuiteScript customization and custom fields on the vendor record. Will the integration break them?"
Not by default, but they must be surfaced before go-live. We run a NetSuite-side integration health check as part of the design workshop, catalogue every custom field and SuiteScript touchpoint in scope, classify each NetSuite-side or Zycus-side, assign an owner, and set a resolution milestone before SIT. Included under Model A, not an extra.
Where we go from here
Three decisions that unlock the design
None require a long lead time. They can be resolved in one working session with the right people: your NetSuite administrator, your iPaaS or SuiteScript contact, and your procurement lead.
Choose the integration model
Model A (iSaaS-led) or Model B (customer-owned). Determines who builds the mapping, who owns any RESTlet, and your resource commitment.
Unlocks: effort estimate + timeline
Confirm the touchpoint and subsidiary inventory
Walk each touchpoint and each in-scope subsidiary: vendor, PO, vendor bill, SSO, TPRM, spend feeds. Each gets a yes or no. Confirm the integration role's permissions and OAuth 2.0 posture.
Unlocks: scope boundary + baseline
Run the integration design workshop
One day. NetSuite admin, Zycus team, iPaaS team if applicable. Run the GenAI mapping session live. Exit with a signed-off integration design document.
Unlocks: build can start
Ready to lock the design?
One working session. The right people. A signed-off integration design document.
