ACF Connector Specification — NetSuite
1. Purpose
This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with Oracle NetSuite.
NetSuite is treated as a source enterprise resource planning and accounting platform rather than as an import/export file format.
The preferred ZAYAZ architecture uses:
- SuiteTalk REST Web Services for governed record access;
- SuiteQL for financial, analytical and joined source queries;
- SuiteAnalytics Connect where large read-only extraction workloads justify it; and
- RESTlets or SuiteScript adapters only when the standard source interfaces do not provide the required capability.
The connector enables authorized NetSuite data to participate safely in:
- ESG screening;
- emissions estimation;
- vendor and item classification;
- project and organizational allocation;
- multi-entity ESG processing;
- evidence collection;
- reporting prepopulation;
- audit and assurance;
- reconciliation; and
- regulatory data-quality evaluation.
The connector does not treat accounting data as sustainability evidence merely because it exists in NetSuite.
ACF determines:
- which NetSuite account and environment is connected;
- which role and permissions govern the connection;
- which subsidiaries and legal entities are represented;
- which standard and custom records are available;
- what each source field can reliably establish;
- what ZAYAZ may derive from those fields;
- what requires additional evidence; and
- how every material result remains traceable to its source.
2. Connector model
NetSuite is a metadata-driven enterprise ERP connector.
A typical production architecture is:
NETSUITE
│
┌──────────────┼──────────────┐
│ │ │
SuiteTalk REST SuiteQL SuiteAnalytics
│ │ Connect
│ │ │
└──────────────┼──────────────┘
│
▼
ZAYAZ API Hub
│
Account Profile
│
▼
TrustGate
│
▼
ACF
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Normalize Validate Classify
│ │ │
└───────────┼───────────┘
▼
Canonical Data
│
┌─────────────┼─────────────┐
▼ ▼ ▼
MICE FOGE ZARA
│
▼
Governed ESG Data
RESTlets and SuiteScript sit outside the normal path and are introduced only when required.
3. Why NetSuite requires account-specific discovery
NetSuite accounts are highly configurable.
Two organizations using NetSuite may expose materially different source models because of differences in:
- enabled features;
- OneWorld configuration;
- subsidiaries;
- SuiteTax configuration;
- SuiteApps;
- custom records;
- custom fields;
- custom transaction types;
- role permissions; and
- organization-specific workflows.
Therefore:
There is no single static NetSuite schema that ACF should assume for every customer.
The connector must discover and register the effective customer schema.
4. REST metadata catalog
SuiteTalk REST provides a metadata catalog for exposed records.
This is particularly useful to ZAYAZ because metadata can be retrieved in formats including:
JSON
OpenAPI 3.0
JSON Schema
The connector should use this metadata to build the customer-specific ACF profile.
For example:
NetSuite metadata
│
├── standard records
├── available fields
├── custom fields
├── subrecords
└── supported operations
│
▼
ACF-NETSUITE-CUSTOMER-PROFILE
This profile becomes part of the governed connector state.
5. Records Catalog and SuiteQL schema
The REST metadata catalog and the NetSuite Records Catalog solve related but different problems.
The REST metadata catalog describes record-service capabilities.
The Records Catalog helps identify fields and joins available through the analytics data source and indicates availability across surfaces such as:
- SuiteAnalytics Workbook;
- SuiteScript;
- SuiteTalk REST Web Services; and
- SuiteAnalytics Connect.
ACF should therefore evaluate both where required.
A field that is unavailable through the REST record API may still be accessible through SuiteQL.
6. Authentication strategy
New ZAYAZ integrations must use OAuth 2.0.
Two models are supported.
6.1 OAuth 2.0 authorization-code flow
Appropriate where an authorized NetSuite user explicitly grants application access.
Typical flow:
ZAYAZ
│
▼
NetSuite authorization
│
▼
user grants role-based access
│
▼
OAuth tokens
│
▼
authorized NetSuite API
6.2 OAuth 2.0 client-credentials flow
Appropriate for controlled server-to-server integration.
NetSuite maps:
application
+
certificate
+
entity
+
role
to the machine-to-machine integration identity.
This is particularly appropriate for enterprise production integrations where ongoing human authorization is not desirable.
Private keys must remain in the ZAYAZ secrets infrastructure.
7. TBA is legacy
NetSuite Token-Based Authentication has historically been widely used for integrations.
It must not be selected for new ZAYAZ connectors.
The architecture should instead assume:
TBA
│
│ legacy
▼
OAuth 2.0
Existing customer TBA integrations may be recognized during migration assessment.
They should not define the target ACF architecture.
8. SOAP is also legacy
SuiteTalk SOAP Web Services must not be used for new ZAYAZ connectors.
The migration direction is:
SuiteTalk SOAP
│
▼
SuiteTalk REST
Legacy SOAP integrations may be analyzed when onboarding an existing enterprise customer, but ZAYAZ should not build new product capability around SOAP semantics.
9. Account-specific URLs
NetSuite REST services use account-specific domains.
ZAYAZ must resolve and store the service URL as connector configuration rather than constructing or hard-coding assumptions about NetSuite infrastructure.
The identity of a source connection therefore includes:
NetSuite account
+
environment
+
service URL
+
OAuth integration
+
role
10. Production, Sandbox and Release Preview
NetSuite production, Sandbox and Release Preview environments must be treated as distinct connector environments.
Authorization state must not be assumed to transfer between them.
ACF distinguishes:
PRODUCTION
SANDBOX
RELEASE PREVIEW
Release Preview is strategically valuable because it can allow ZAYAZ to test upcoming NetSuite changes before the customer's production account is upgraded.
This can become part of schema-drift prevention.
11. Connector preflight
Before activation, ZAYAZ should perform a governed preflight.
The process is:
Resolve account
↓
Resolve environment
↓
Authenticate
↓
Resolve role
↓
Inspect metadata
↓
Inspect enabled capabilities
↓
Resolve subsidiaries
↓
Validate mappings
↓
Register snapshot
↓
Activate connector profile
The result is:
ACF-NETSUITE-CUSTOMER-PROFILE
12. SuiteTalk REST Web Services
SuiteTalk REST is the preferred transactional integration surface.
It can support operations such as:
- retrieving records;
- filtering record collections;
- creating records where authorized;
- updating records where authorized;
- deleting records where authorized;
- accessing subresources;
- inspecting metadata; and
- resolving related records.
ZAYAZ is expected to be primarily a reader of accounting source data.
Write operations must be enabled only for explicit governed use cases.
13. SuiteQL
SuiteQL is the preferred source interface for many analytical accounting queries.
It is particularly useful where ACF needs to:
- join related records;
- retrieve large transaction populations;
- reconcile source data;
- perform incremental queries;
- inspect accounting dimensions;
- retrieve ledger data; or
- analyze data across record types.
Conceptually:
SuiteTalk REST
│
├── authoritative record retrieval
│
└── object relationships
SuiteQL
│
├── analytical retrieval
│
├── joined datasets
│
└── reconciliation
The two interfaces are complementary.
14. SuiteQL result governance
SuiteQL through REST has a finite result boundary.
ZAYAZ must therefore avoid unbounded extraction queries.
Large requests should be partitioned using deterministic source criteria such as:
- accounting period;
- transaction date;
- subsidiary;
- internal ID range;
- transaction type; or
- another stable filter.
Where a dataset exceeds the appropriate REST extraction model, SuiteAnalytics Connect may be used if available.
15. Bound SuiteQL parameters
Dynamic query values should use supported bound parameters rather than concatenating untrusted values into query text.
Conceptually:
query definition
+
bound values
↓
SuiteQL execution
This should be the default pattern for generated or parameterized queries.
Material SuiteQL queries must also remain traceable.
TrustGate should retain either the governed query definition or an immutable query hash together with relevant parameters.
16. SuiteAnalytics Connect
SuiteAnalytics Connect provides a read-only analytics interface.
It is useful for workloads such as:
- very large historical extracts;
- enterprise reconciliation;
- bulk transaction analysis; and
- analytical warehouse-style ingestion.
It supports interfaces including:
- ODBC;
- JDBC; and
- ADO.NET.
It should not be used as a substitute for transactional REST integration.
The preferred architecture is:
REST / SuiteQL
│
operational connector
SuiteAnalytics Connect
│
optional large-scale reader
17. RESTlets
RESTlets provide custom NetSuite integration logic through SuiteScript.
They can be valuable when:
- a required source operation is absent from standard REST;
- customer-specific business logic must execute inside NetSuite;
- several internal actions need to be composed; or
- a customer SuiteApp exposes an approved integration surface.
But this flexibility has a governance cost.
A RESTlet is executable customer-specific integration logic.
Therefore it requires:
- versioning;
- deployment identity;
- change control;
- input validation;
- output-schema validation;
- security review; and
- TrustGate registration.
18. Event-driven synchronization
NetSuite should not be modeled as having a universal native webhook capability equivalent to an event-native SaaS platform.
The standard production ACF model is therefore:
Initial synchronization
↓
Incremental filtered retrieval
↓
Periodic reconciliation
Where stronger event-driven behavior is required, a customer may deploy:
- SuiteScript;
- workflow integration;
- middleware; or
- another approved source adapter.
Such eventing supplements rather than replaces reconciliation.
19. Incremental synchronization
Incremental retrieval should use source-supported change indicators where available.
Typical strategy:
last successful watermark
↓
overlap window
↓
filtered source query
↓
stable ordering
↓
deduplication
↓
new watermark
The overlap window protects against timing boundaries and late source changes.
Processing must be idempotent.
20. NetSuite governance limits
NetSuite controls API concurrency at the account level.
This is an important connector characteristic.
ZAYAZ must not assume an unlimited API surface.
Connector throughput may depend on:
- NetSuite service tier;
- SuiteCloud Plus licensing;
- concurrent external integrations; and
- customer-specific account usage.
Therefore ZAYAZ should use adaptive throttling.
normal capacity
│
▼
parallel requests
│
governance pressure?
│
┌──┴──┐
no yes
│ │
▼ ▼
continue reduce concurrency
+
backoff
21. Shared concurrency
NetSuite web services and RESTlet workloads can share account-level concurrency capacity.
This means ZAYAZ cannot consider its connector in isolation.
Another customer integration may consume part of the same available capacity.
The connector should therefore monitor:
- concurrency failures;
- latency;
- retry rates;
- source timeouts; and
- sustained governance pressure.
Non-critical ESG work may be delayed rather than competing with critical accounting integrations.
22. Source identities
NetSuite internal IDs should be preserved.
Where available, external IDs should also be retained.
The canonical source identity should normally include:
NetSuite account
+
record type
+
internal ID
+
subsidiary where relevant
For transaction lines:
parent transaction
+
line identity
+
record context
should be preserved where the source model allows it.
23. OneWorld and subsidiaries
NetSuite OneWorld is especially important to ZAYAZ.
A OneWorld account represents a hierarchy of subsidiaries.
Each subsidiary can represent a separate legal entity.
Therefore:
NetSuite Account
│
├── Subsidiary A
├── Subsidiary B
├── Subsidiary C
└── Elimination Subsidiary
must not be collapsed automatically into one ZAYAZ company.
Each relevant subsidiary must resolve to:
ZAYAZ organization context
+
E-C-O Number
before ESG processing.
24. Financial consolidation is not ESG consolidation
This distinction is critical.
NetSuite may consolidate financial entities according to accounting rules.
ZAYAZ may need to consolidate sustainability data according to a different applicable methodology.
Therefore:
NetSuite financial boundary
must not automatically become:
ZAYAZ GHG / ESRS / ESG reporting boundary
The organizational-boundary methodology remains separately governed.
25. Intercompany transactions
OneWorld may contain intercompany transactions.
Without appropriate controls, these can create ESG double counting.
ACF must retain:
- originating subsidiary;
- receiving subsidiary or subsidiaries;
- transaction type;
- source transaction identity;
- elimination context where applicable; and
- consolidation treatment.
A simple rule such as:
sum all financial expenditure
would be unsafe in a multi-entity group.
26. General ledger
The NetSuite general ledger can support:
- spend screening;
- financial reconciliation;
- account classification;
- entity reconciliation;
- Scope 3 screening;
- project allocation; and
- ESG evidence discovery.
However:
A ledger posting is a financial fact, not automatically a physical ESG activity.
For example:
EUR 45,000 fuel expense
does not itself prove:
30,000 litres diesel
Physical activity requires supporting activity evidence.
27. Vendors
NetSuite vendor records are important ESG master data.
A vendor relationship may support:
- supplier identification;
- spend aggregation;
- supplier-country mapping;
- supplier questionnaire routing;
- CSDDD workflows;
- supplier-risk analysis;
- supplier-specific emissions requests; and
- Scope 3 analysis.
However:
known vendor
does not mean:
verified supplier ESG data
The data-quality distinction remains explicit.
28. Vendor bills
Vendor bills can materially improve ESG classification beyond general-ledger data.
Potentially useful context includes:
- vendor;
- transaction date;
- subsidiary;
- currency;
- item or expense lines;
- account;
- memo;
- project or other dimensions; and
- related records.
Some REST-specific field limitations exist.
ACF must therefore determine whether the needed data should come from:
REST record
│
├── sufficient → use
│
└── insufficient
↓
SuiteQL?
│
┌──────┴──────┐
yes no
│ │
use enrichment /
approved adapter
29. Purchase orders
Purchase-order data can help identify procurement intent before final accounting recognition.
This may be useful for:
- purchased-goods classification;
- supplier analysis;
- quantity discovery;
- project procurement;
- Scope 3 estimation; and
- forecasting.
However, standard REST exposure has record-specific limitations.
Therefore purchase-order line capability must be established through the customer's connector profile rather than assumed.
SuiteQL may provide a better retrieval route for some analytical purchase-order data.
30. Items and inventory
NetSuite item and inventory records can materially improve product and activity classification.
Potential uses include:
- item-level ESG category mapping;
- inventory movement analysis;
- product-specific supplier mapping;
- quantity-based activity discovery;
- materials analysis;
- procurement classification; and
- product-footprint enrichment.
For example:
Vendor bill line
+
inventory item
+
quantity
+
unit
↓
potential activity-level ESG input
This is significantly stronger than account-only classification.
31. Item receipts
Item receipts can help distinguish:
ordered quantity
from:
physically received quantity
That difference may matter for:
- procurement analytics;
- inventory emissions;
- material-flow analysis;
- supplier performance; and
- product-level environmental modeling.
Item receipt data must still be mapped to the applicable ESG methodology before use.
32. Expense reports
Employee expense reports may support sustainability analysis of:
- travel;
- accommodation;
- mileage;
- transport;
- meals;
- other employee expenditure.
The availability and quality of the source data depend on how the customer uses the NetSuite feature.
Expense value alone may support screening.
Activity-based calculation requires appropriate physical data.
33. Projects
Projects and project tasks can provide valuable ESG allocation dimensions.
Examples include:
- construction footprint;
- professional-services project emissions;
- infrastructure projects;
- customer project sustainability;
- project procurement;
- project travel;
- project profitability versus environmental impact.
NetSuite's REST exposure for project data has field and sublist limitations.
ACF must therefore use account-specific capability discovery.
34. Departments, classes and locations
NetSuite organizational dimensions may support ESG allocation.
For example:
NetSuite location
↓
ZAYAZ facility
NetSuite department
↓
ZAYAZ organizational unit
NetSuite class
↓
customer-specific semantic category
These relationships must be governed mappings.
A dimension name must never be treated as its semantic meaning without mapping.
35. Custom dimensions and fields
This is a major NetSuite strength.
Customers frequently use custom fields to encode business information specific to their organization.
Examples could include:
vehicle type
fuel type
site
project category
supplier classification
business unit
product family
contract
operating region
Such fields may dramatically improve ESG classification.
But custom fields are account-specific.
Therefore:
ZAYAZ should discover them, not hard-code them.
36. Custom-field semantic mapping
Discovery is only the first step.
A custom NetSuite field such as:
custbody_region_code
does not automatically tell ZAYAZ what it means.
The mapping process is:
custom field
↓
metadata discovery
↓
semantic assessment
↓
canonical mapping
↓
governed mapping version
Once governed, the field may become a powerful classification signal.
37. Tax and SuiteTax
NetSuite tax behavior requires special handling.
The connector must determine whether the relevant customer uses supported SuiteTax functionality.
REST support must not be generalized from one record to another.
Tax data may help:
- determine net versus gross values;
- understand transaction semantics;
- classify expenditure; and
- validate financial amounts.
It is not itself an ESG methodology.
38. Currency
NetSuite may contain:
- transaction currency;
- subsidiary base currency;
- group reporting currency; and
- converted accounting amounts.
ACF must distinguish these.
An ESG spend-based calculation should record:
source amount
source currency
↓
governed currency conversion
↓
factor reference currency/year
↓
calculation
The normalized amount is a ZAYAZ transformation.
It must not replace the original NetSuite value.
39. ESG processing model
The source-to-result chain is:
NetSuite source record
↓
ACF source registration
↓
canonical mapping
↓
normalization
↓
classification
↓
method selection
↓
factor resolution
↓
MICE
↓
TrustGate
↓
governed ESG result
NetSuite answers:
What happened in the enterprise system?
ZAYAZ determines:
What sustainability meaning can validly be derived from it?
40. Spend-based emissions
NetSuite is well suited to spend-based screening because it can supply multiple classification signals.
For example:
Vendor
+
GL account
+
Vendor bill
+
Item
+
Project
+
Department
+
Location
+
Custom fields
↓
ESG classification
↓
spend category
↓
factor resolution
↓
tCO2e
This can be substantially stronger than account-only classification.
But the result remains an estimate unless higher-quality evidence exists.
41. Activity-based emissions
Activity-based calculation requires valid physical activity.
Examples include:
- kWh;
- litres;
- kg;
- tonnes;
- km;
- passenger-km;
- tonne-km;
- units of material; or
- another method-compatible quantity.
An item line may contain useful quantity information.
That quantity is not automatically a valid environmental activity.
ZAYAZ must establish:
quantity
+
unit
+
activity meaning
+
method
+
factor
before calculation.
42. Data-quality hierarchy
ACF applies the common accounting data-quality hierarchy.
ACF-DQ1 — Accounting-only estimate
Examples:
- GL account;
- transaction;
- vendor;
- spend;
- memo.
Typical use:
- screening;
- materiality;
- spend-based estimation.
ACF-DQ2 — Invoice-level data
Examples:
- vendor bill;
- invoice;
- transaction line;
- purchase record;
- item;
- linked evidence.
This can significantly improve classification.
ACF-DQ3 — Activity data
Physical quantity and unit are available.
Examples:
14,200 kWh
860 litres
24.5 tonnes
9,400 passenger-km
ACF-DQ4 — Supplier-specific data
Data is attributable to the actual supplier, product or service.
ACF-DQ5 — Verified primary data
The primary data has undergone the required validation or verification.
43. Quality upgrades
The hierarchy supports progressive improvement.
DQ1
Accounting estimate
│
▼
DQ2
Transaction-line estimate
│
▼
DQ3
Activity calculation
│
▼
DQ4
Supplier-specific result
│
▼
DQ5
Verified primary result
A higher-quality result may supersede a previous calculation.
It must not erase its history.
TrustGate preserves the calculation chain.
44. Classification
NetSuite provides unusually rich potential classification context.
A classification decision may use:
account
vendor
transaction type
item
memo
project
department
class
location
subsidiary
custom fields
The result remains a ZAYAZ-derived classification unless NetSuite explicitly supplied the same semantic classification.
45. Evidence linkage
NetSuite records may act as evidence or evidence locators.
Examples include:
- vendor bill;
- invoice;
- journal entry;
- expense report;
- purchase order;
- item receipt;
- item;
- project;
- vendor;
- custom record; and
- related document.
TrustGate preserves the relationship.
Example:
ESRS datapoint
↓
ZAYAZ emissions result
↓
MICE execution
↓
classified activity
↓
NetSuite vendor bill line
↓
vendor bill
↓
vendor
↓
subsidiary
↓
source identity
46. FOGE prepopulation
FOGE can use validated NetSuite-derived information where the reporting requirement permits it.
Example:
NetSuite source
↓
ACF validation
↓
evidence quality test
↓
MICE calculation
↓
reporting requirement test
↓
FOGE prepopulation
The mere presence of accounting data does not authorize prepopulation.
The evidence must satisfy the relevant reporting requirement.
47. Reporting limitations
NetSuite cannot independently populate a complete ESRS, VSME or other sustainability report.
Accounting data may support:
- emissions inputs;
- financial denominators;
- supplier information;
- energy or procurement screening;
- organizational structures;
- project allocations; and
- evidence links.
It does not by itself prove:
- policies;
- transition plans;
- governance responsibilities;
- workforce practices;
- due-diligence processes;
- stakeholder engagement;
- biodiversity assessments;
- targets; or
- narrative disclosures.
48. ZARA behavior
ZARA uses the NetSuite connector profile to answer questions such as:
- Is this field actually available?
- Is the field REST-native or SuiteQL-derived?
- Which subsidiary does the transaction belong to?
- Why was a particular vendor classification selected?
- Why is additional evidence required?
- What quality tier applies?
- Why did a recalculation change?
- Is this value NetSuite-native or ZAYAZ-derived?
ZARA must keep source fact and derived interpretation separate.
49. FOGE behavior
FOGE uses:
- source availability;
- evidence sufficiency;
- quality tier;
- subsidiary context;
- reporting requirement;
- source preference; and
- enrichment state.
FOGE should never transform:
NetSuite has data
into:
regulatory disclosure requirement satisfied
without validation.
50. MICE behavior
MICE receives governed calculation inputs.
A calculation should identify:
- NetSuite source record;
- subsidiary;
- reporting entity;
- financial amount or activity;
- source currency;
- normalized currency where applicable;
- classification;
- method;
- emission factor;
- factor version;
- reporting period;
- data-quality tier; and
- provenance.
This allows deterministic reproduction.
51. COSE behavior
COSE compares available evidence against regulatory and methodological requirements.
Example:
Required:
verified physical electricity consumption
Available:
NetSuite utility vendor bill
with financial amount only
Result:
evidence gap
The correct outcome is not to invent consumption.
The correct outcome is to request enrichment.
52. DaVE behavior
DaVE monitors both connector health and data quality.
Signals include:
- authentication failure;
- role change;
- metadata drift;
- custom-field change;
- SuiteQL failure;
- governance pressure;
- synchronization lag;
- reconciliation difference;
- missing subsidiary mapping;
- supplier-resolution failure;
- unexpected data variance; and
- closed-period mutation.
A technically connected NetSuite account can therefore still be marked degraded for ESG use.
53. TrustGate behavior
TrustGate preserves:
NetSuite
↓
source retrieval
↓
canonical mapping
↓
normalization
↓
classification
↓
calculation
↓
reporting output
↓
verification
The lineage must survive:
- source correction;
- transaction reversal;
- late posting;
- period reopening;
- mapping change;
- custom-field change;
- methodology change;
- factor change;
- manual override; and
- assurance review.
54. Historical changes
Historical accounting records can change.
Examples include:
- late vendor bills;
- journal corrections;
- reversals;
- reopened periods;
- intercompany changes;
- changed project allocations; and
- updated custom fields.
When a material source record changes:
NetSuite mutation
↓
DaVE detection
↓
TrustGate lineage event
↓
affected ESG result identified
↓
revalidation
↓
recalculation if required
The previous result remains auditable.
55. Data minimization
NetSuite can contain substantial information unrelated to a specific ESG purpose.
ZAYAZ should retrieve only what is needed.
For example:
Required:
vendor
amount
currency
account
subsidiary
project
transaction date
does not justify indiscriminate extraction of:
all employee data
all CRM data
all communications
all unrelated custom fields
Source-side filtering is therefore part of privacy and security architecture.
56. Custom records
Custom NetSuite records can be extremely valuable.
They may contain customer-specific information such as:
- fleet records;
- facility records;
- meter data;
- supplier attributes;
- material data;
- product attributes;
- operational measurements; or
- sustainability-specific extensions.
However, their semantics are customer-specific.
They require:
metadata discovery
↓
semantic mapping
↓
schema registration
↓
governed use
57. REST gaps
A recurring NetSuite integration mistake would be:
field not returned by REST
↓
field does not exist
ACF must not make this assumption.
The proper process is:
not in REST response
↓
metadata?
↓
SuiteQL?
↓
feature enabled?
↓
role permission?
↓
custom source?
↓
truly unavailable?
Only then should ZAYAZ mark the field unavailable.
58. Preferred production architecture
The preferred deployment is:
ORACLE NETSUITE
│
┌──────────────┼───────────────┐
│ │ │
SuiteTalk REST SuiteQL SuiteAnalytics
│ │ Connect
│ │ optional
└──────────────┼───────────────┘
│
▼
ZAYAZ API HUB
│
account + schema profile
│
▼
TRUSTGATE
│
source lineage
│
▼
ACF
┌─────────────┼─────────────┐
│ │ │
normalize validate classify
│ │ │
└─────────────┼─────────────┘
▼
CANONICAL DATA MODEL
│
┌─────────────┼─────────────┐
│ │ │
MICE FOGE ZARA
│ │ │
└─────────────┼─────────────┘
▼
GOVERNED ESG OUTPUT
RESTlets or SuiteScript adapters are added only where explicitly required.
59. Quick-start implementation
A controlled pilot should:
- establish a NetSuite Sandbox connection where available;
- configure OAuth 2.0;
- retrieve account-specific metadata;
- generate the ACF customer profile;
- map subsidiaries;
- map key accounts and dimensions;
- retrieve a limited historical period;
- validate vendors and transaction relationships;
- perform initial ESG screening;
- test SuiteQL reconciliation;
- validate TrustGate lineage; and
- verify API governance behavior.
Production activation should not occur solely because records can be retrieved.
60. Production implementation
Production should add:
- governed OAuth 2.0 credentials;
- certificate rotation where applicable;
- adaptive API throttling;
- scheduled incremental synchronization;
- reconciliation;
- schema-drift monitoring;
- custom-field monitoring;
- subsidiary mapping;
- closed-period mutation detection;
- TrustGate registration;
- quality diagnostics;
- controlled recalculation; and
- production observability.
61. OneWorld implementation
For OneWorld customers, connector activation requires an additional entity gate.
NetSuite subsidiary
↓
legal entity?
↓
ZAYAZ organization
↓
E-C-O Number
↓
reporting boundary
Elimination subsidiaries and intercompany structures must also be identified.
No transaction should enter a group sustainability calculation without entity context where that context is material.
62. High-volume implementation
Where customer data volumes exceed the practical REST/SuiteQL extraction profile:
normal operational reads
↓
REST / SuiteQL
while:
large historical or analytical extract
↓
SuiteAnalytics Connect
may be preferable.
Both paths feed the same ACF canonical and lineage model.
The downstream system should not need to know which transport supplied the record unless provenance is being inspected.
63. Limitations
The connector has several material limitations.
63.1 Customer schemas vary
Standard and custom fields differ between accounts.
63.2 Feature availability varies
Projects, OneWorld, SuiteTax, SuiteAnalytics Connect and other capabilities may not be enabled.
63.3 REST coverage is record-specific
A REST-supported record does not imply every field or sublist is exposed.
63.4 Role permissions affect visibility
Missing values may reflect authorization rather than absent business data.
63.5 API capacity is governed
Large extraction workloads must respect NetSuite account concurrency.
63.6 SuiteQL REST is not unlimited bulk export
Large datasets require partitioning or an appropriate alternative such as SuiteAnalytics Connect.
63.7 Generic native webhooks should not be assumed
Event-driven behavior requires additional integration design.
63.8 Accounting data remains accounting data
Financial records alone cannot prove every environmental activity or regulatory disclosure.
64. Connector activation gate
A production NetSuite connection should not activate until:
OAuth 2.0 PASS
Account URL PASS
Role permissions PASS
Metadata snapshot PASS
Custom-field discovery PASS
Subsidiary mapping PASS / N/A
Canonical mapping PASS
TrustGate registration PASS
Initial reconciliation PASS
Governance test PASS
Monitoring PASS
Additional controls may apply to:
- SuiteAnalytics Connect;
- RESTlets;
- custom SuiteScript;
- OneWorld;
- intercompany processing; or
- customer-specific records.
65. Definition of done
The NetSuite connector is production-ready when ZAYAZ can demonstrate that it can:
- authenticate through OAuth 2.0;
- resolve the correct account-specific services;
- identify the effective role and permissions;
- discover account-specific metadata;
- identify standard and custom records and fields;
- resolve subsidiary context where applicable;
- retrieve required accounting objects;
- execute governed SuiteQL queries;
- preserve NetSuite source identities;
- map source data into the ZAYAZ canonical model;
- normalize and validate it deterministically;
- perform controlled incremental synchronization;
- reconcile source state;
- operate within NetSuite governance limits;
- detect metadata and mapping drift;
- detect relevant historical accounting mutations;
- prevent intercompany ESG double counting;
- execute ESG screening without inventing missing activity;
- upgrade calculations when higher-quality evidence becomes available;
- retain prior calculations and provenance;
- support ZARA, FOGE, MICE, COSE, DaVE and TrustGate consumers;
- prevent cross-tenant and cross-subsidiary leakage;
- govern any RESTlet or SuiteScript extension; and
- reproduce any material ESG result from source to final output.
66. Source references
The connector specification is based primarily on current official Oracle NetSuite documentation covering:
- SuiteTalk REST Web Services;
- REST metadata;
- Records Catalog;
- SuiteQL;
- OAuth 2.0;
- OAuth 2.0 client credentials;
- account-specific URLs;
- RESTlets;
- SuiteAnalytics Connect;
- API concurrency governance;
- NetSuite OneWorld;
- REST record limitations;
- TBA migration; and
- SOAP Web Services removal.
For implementation purposes, the customer's current NetSuite metadata and Records Catalog remain authoritative for account-specific record and field availability.
The ACF customer connector profile must be reviewed or regenerated when material changes affect:
- the NetSuite release;
- enabled features;
- role permissions;
- standard records;
- custom records;
- custom fields;
- subsidiaries;
- SuiteApps;
- taxation configuration;
- authentication; or
- integration architecture.
Runtime Provider Extension
The provider-specific runtime contract for this connector is maintained separately from the common ACF connector frontmatter.
It contains machine-actionable provider semantics that are intentionally not part of the common ACF schema, including authentication lifecycle, provider object revision semantics, change-capture constraints and provider-specific capability rules.
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-NETSUITE
provider:
namespace: oracle.netsuite
name: Oracle
product: NetSuite
runtime:
source_contract:
primary_api: suitetalk_rest
suiteql_supported: true
suiteanalytics_connect_supported_for_high_volume: true
metadata_account_specific: true
metadata_formats:
- json_schema
- openapi_3
source_identity:
account_context_required: true
subsidiary:
candidate_id_class: ECO
automatic_legal_entity_resolution_allowed: false
capability_rules:
account_features_material: true
account_specific_schema_material: true
custom_records_and_fields_dynamic: true
change_capture:
generic_tripletex_style_webhook_assumed: false
reconciliation_required: true
source_semantics:
department:
candidate_id_class: EBU
automatic_resolution_allowed: false
class:
candidate_id_class: EBU
automatic_resolution_allowed: false
location:
source_context: facility_or_organizational_unit_candidate
automatic_resolution_allowed: false
evidence:
source_record_relationships_supported: true
extensions:
preferred_authentication:
oauth_2_0: true
oneworld:
subsidiary_model_supported: true
governance:
status: active
last_verified: 2026-08-30
review_interval_days: 90
change_control_required: true
source_basis: connector_specification