Which direction does data move between Oracle NetSuite and Tradeshift?

The primary flow is from Tradeshift into Oracle NetSuite. Vendor invoices and credit notes from Tradeshift are posted as vendor bills in Oracle NetSuite, matched to the correct purchase orders and GL accounts. Purchase orders can also flow from Oracle NetSuite to Tradeshift so suppliers see the orders on the network. GL postings are read from Oracle NetSuite but not written back to Tradeshift.

How does ml-connector handle the OAuth 1.0a vs OAuth 2.0 difference between the two platforms?

ml-connector stores both credential sets encrypted: OAuth 2.0 certificate and client ID for Oracle NetSuite, and OAuth 1.0a consumer key, secret, and tenant ID for Tradeshift. For each Tradeshift request, it computes the OAuth 1.0a signature and includes the X-Tradeshift-TenantId header. For Oracle NetSuite, it requests a fresh OAuth 2.0 access token before each poll cycle and caches it for the 60-minute lifetime.

What happens if a vendor or GL account from a Tradeshift invoice does not exist in Oracle NetSuite?

ml-connector surfaces the mismatch in the audit log so the mapping can be corrected before the next poll cycle. The invoice is not posted into Oracle NetSuite until the vendor and GL account are either found in the system or a new mapping rule is configured. This prevents incomplete or orphan records in the ledger.

Oracle NetSuiteTradeshift

Oracle NetSuite and Tradeshift integration

Oracle NetSuite runs your enterprise accounting and procurement. Tradeshift connects you to a global network of suppliers and automated invoice processing. The two platforms speak different languages: NetSuite uses REST and OAuth 2.0, Tradeshift uses OAuth 1.0a and UBL XML documents. Connecting them keeps your AP records in sync without manual entry. Vendor invoices from Tradeshift post into Oracle NetSuite as vendor bills against the correct purchase orders, and reference data such as vendor codes and GL accounts stays aligned across both platforms.

How Oracle NetSuite works

Oracle NetSuite exposes vendors, vendor bills, purchase orders, invoices, GL accounts, departments, and locations through the SuiteTalk REST API, authenticated via OAuth 2.0 Client Credentials with a certificate or token-based authentication. Event Subscriptions can push real-time notifications when vendor bills or purchase orders are created or edited, or ml-connector can poll via SuiteQL queries for bulk reads of vendor records and transaction history. Vendor bill details including line amounts, tax, and GL posting details are accessible via REST record endpoints. NetSuite tokens are valid for 60 minutes, and there is no refresh token in the Machine-to-Machine flow, so each request flow must handle token refresh.

How Tradeshift works

Tradeshift exposes vendor invoices, purchase orders, credit notes, receipts, despatch advice, and remittance advice as UBL 2.0 and UBL 2.2 XML documents via the documents/v2 REST endpoint. Authentication uses OAuth 1.0a with consumer key, secret, token, and tenant ID, all required on every call. Tradeshift does not expose native GL accounts or dimensions through a dedicated API; those are embedded in the XML line items as classification codes. Polling is done via the changedAfter timestamp parameter to retrieve documents modified after a given moment. The platform also supports a continuous event stream using protobuf messages, though this requires app registration and custom client code.

What moves between them

The primary flow is from Tradeshift into Oracle NetSuite. ml-connector polls Tradeshift's documents/v2 endpoint periodically to retrieve new and updated vendor invoices and credit notes, extracts the UBL XML fields, maps vendor identifiers and line-item GL codes to matching Oracle NetSuite vendors and GL accounts, and writes the records as vendor bills in Oracle NetSuite. The inverse flow is optional: purchase orders created in Oracle NetSuite can be published to Tradeshift so suppliers see the orders on the network and respond with matching invoices. GL postings are read from Oracle NetSuite but not written back to Tradeshift, keeping the network focused on document exchange rather than ledger updates.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the OAuth 2.0 certificate and client ID for Oracle NetSuite, and the OAuth 1.0a consumer key, secret, and tenant ID for Tradeshift. For every request to Tradeshift, it computes the OAuth 1.0a signature and includes the X-Tradeshift-TenantId header. For Oracle NetSuite, it requests a fresh OAuth 2.0 access token before each poll cycle and caches it for the 60-minute lifetime. The integration parses UBL 2.0 documents from Tradeshift, extracting invoice number, date, vendor identifier, line items, and tax amounts, then translates those into the Oracle NetSuite vendor bill record format, matching vendor names to NetSuite vendor records and line-item GL codes to NetSuite GL accounts using a configurable mapping table. If a vendor or GL account does not exist in Oracle NetSuite, ml-connector surfaces the mismatch in the audit log so the mapping can be corrected before the next poll cycle. Purchase orders flow the opposite direction using the same vendor and account mapping. Tradeshift documents use UBL XML format identified by documentProfileId, so ml-connector must parse and validate that structure on ingest. Because Tradeshift has no native webhooks, all reads are polling-based with the changedAfter filter to minimize repeated downloads. Every invoice, PO, and mapping mismatch carries a full audit trail and can be manually replayed if a downstream GL posting fails.

A real-world example

A mid-sized distributor runs Oracle NetSuite for finance and procurement, and uses Tradeshift to connect with hundreds of suppliers across its supply network. Before the integration, the AP team received invoices from Tradeshift and printed or emailed them to accounting, where staff re-keyed the vendor name, invoice number, line amounts, and GL code into Oracle NetSuite by hand. This created invoice entry delays, duplicate record risks, and month-end reconciliation friction. With Oracle NetSuite and Tradeshift connected, each supplier invoice from Tradeshift lands in Oracle NetSuite as a vendor bill within minutes, matched to the purchase order, and posted to the correct GL account based on the line-item classification. The AP team now reviews exceptions in the audit log and approves batches for payment, eliminating manual entry.

What you can do

Poll Tradeshift for new vendor invoices and credit notes, and post them into Oracle NetSuite as vendor bills matched to purchase orders.
Translate UBL 2.0 XML documents from Tradeshift into Oracle NetSuite vendor bill records with line-item GL posting.
Map vendor identifiers and GL account codes from Tradeshift documents to matching Oracle NetSuite vendor records and GL accounts.
Handle OAuth 2.0 token refresh for Oracle NetSuite and OAuth 1.0a signature generation for Tradeshift on every request.
Publish Oracle NetSuite purchase orders to Tradeshift so suppliers can view orders on the network and respond with matching invoices.

Questions

Which direction does data move between Oracle NetSuite and Tradeshift?: The primary flow is from Tradeshift into Oracle NetSuite. Vendor invoices and credit notes from Tradeshift are posted as vendor bills in Oracle NetSuite, matched to the correct purchase orders and GL accounts. Purchase orders can also flow from Oracle NetSuite to Tradeshift so suppliers see the orders on the network. GL postings are read from Oracle NetSuite but not written back to Tradeshift.
How does ml-connector handle the OAuth 1.0a vs OAuth 2.0 difference between the two platforms?: ml-connector stores both credential sets encrypted: OAuth 2.0 certificate and client ID for Oracle NetSuite, and OAuth 1.0a consumer key, secret, and tenant ID for Tradeshift. For each Tradeshift request, it computes the OAuth 1.0a signature and includes the X-Tradeshift-TenantId header. For Oracle NetSuite, it requests a fresh OAuth 2.0 access token before each poll cycle and caches it for the 60-minute lifetime.
What happens if a vendor or GL account from a Tradeshift invoice does not exist in Oracle NetSuite?: ml-connector surfaces the mismatch in the audit log so the mapping can be corrected before the next poll cycle. The invoice is not posted into Oracle NetSuite until the vendor and GL account are either found in the system or a new mapping rule is configured. This prevents incomplete or orphan records in the ledger.

Connect Oracle NetSuite and Tradeshift

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started