Ellipse Gradient for Header

Thomson Reuters ONESOURCE Integration Guide

Integrate ONESOURCE tax-determination capabilities with enterprise applications through provisioned REST APIs, authenticated workflows, and supported file exchanges.

Thomson Reuters ONESOURCE integration options at a glance

ONESOURCE Indirect Tax products are commonly integrated through provisioned REST APIs for submitting transactions and receiving tax results. Authentication may use OAuth 2.0, client credentials, API keys, subscription keys, or a combination, depending on the module and tenant. Selected compliance and reporting products may also support batch processing or file-based exchange, but these capabilities require module-specific confirmation. A general GraphQL, SOAP, or webhook model is not confirmed. Martini can consume the applicable ONESOURCE API, transform orders, invoices, addresses, products, and tax data, orchestrate synchronous or scheduled workflows, and route validation, throttling, and reconciliation exceptions.

Integration pointSupported by Thomson Reuters ONESOURCE?Common use casesHow Martini supports it
REST APIsYesONESOURCE Indirect Tax products are commonly integrated through REST-based determination APIs to submit transactions and receive calculated tax results. Other resources and status operations depend on the licensed module and API version.Martini can consume the provisioned ONESOURCE REST API, configure authentication, map request and response payloads, and orchestrate the complete tax-determination workflow.
AuthenticationYesAuthentication may use OAuth 2.0 and client credentials, API keys, subscription keys, application identifiers, scopes, or tenant permissions depending on the product.Martini can store secrets in protected environment configuration, obtain or pass credentials, and apply authenticated API requests without embedding secrets in workflows.
Bulk, asynchronous, or batch APIsLimitedBatch or asynchronous processing may be available in selected compliance, tax-management, or reporting products, but it is not universal across ONESOURCE.Martini can implement scheduled or queued workflows when the customer’s module exposes documented batch or asynchronous operations, with status tracking and reconciliation.
File and attachment exchangeLimitedSelected compliance and reporting workflows may support CSV, XML, or vendor-defined file exchange through an API, secure file transfer, or customer-specific portal.Martini can orchestrate supported file inputs and outputs, validate formats, transform records, and route rejection reports when the transport and format are documented.
Webhooks and outbound callbacksNot confirmedNo general ONESOURCE webhook framework was confirmed. Individual modules may expose callbacks or notifications for selected asynchronous operations.Martini can receive webhook-style notifications when a specific ONESOURCE module documents them, but event types, signing, delivery, and retries must be verified first.
GraphQL APIsNot confirmedNo official ONESOURCE GraphQL interface was confirmed in the research.Martini supports GraphQL consumption generally, but an ONESOURCE GraphQL integration should not be designed unless the customer supplies a confirmed endpoint.
SOAP APIsNot confirmedNo current ONESOURCE SOAP interface was confirmed. Older Thomson Reuters or acquired-product interfaces should not be assumed to apply to current deployments.Martini can consume SOAP services generally, but SOAP should be used for ONESOURCE only when explicitly documented for the customer’s product.
Database and analytics accessNot confirmedDirect database access to ONESOURCE-managed production data is not confirmed. Reporting or analytics exports may be product-specific.Martini can consume vendor-supported exports or APIs, but should not connect directly to ONESOURCE-managed production databases without explicit vendor support.

How Thomson Reuters ONESOURCE exposes data and business events

ONESOURCE REST APIs

ONESOURCE Indirect Tax products are commonly integrated through REST-based APIs. A customer-specific API may accept transaction data for tax calculation, return tax results, and expose additional resources or status operations depending on the licensed module, region, and API version.

Martini implementation pattern

Martini implementation pattern: expose a Martini API or start a workflow from the source application, transform the source transaction into the provisioned ONESOURCE request model, authenticate the REST call, normalize the response, and return or persist the tax result. Martini should use the official customer-specific API specification rather than assuming a universal ONESOURCE endpoint.

Implementation sequence

Receive the order, invoice, or credit document
Validate required transaction, address, product, and amount fields
Map the source document to the ONESOURCE transaction model
Authenticate and submit the REST determination request
Normalize line and document tax results
Write the result back to the source system and record correlation identifiers

ONESOURCE batch and file processing

Selected ONESOURCE compliance, tax-management, and reporting products may support batch, asynchronous, or file-based processing. These capabilities are module-specific and require confirmation of the supported format, transport, status model, and rejection behavior.

Martini implementation pattern

Martini implementation pattern: schedule or trigger a workflow, assemble the approved transaction or reporting file, deliver it through the documented ONESOURCE interface, track processing status where available, and parse result or rejection files. Martini should not assume that a batch or file interface exists for every ONESOURCE deployment.

Implementation sequence

Select eligible transactions or prepare the vendor-required file
Validate the documented format and required identifiers
Deliver the file or batch request through the confirmed transport
Poll or receive the documented processing status
Parse accepted results and rejection details
Reconcile outcomes and route unresolved exceptions

ONESOURCE authentication

Thomson Reuters developer APIs support authenticated application access, while the exact ONESOURCE method depends on the provisioned product. OAuth 2.0 and client credentials should be evaluated first for modern APIs, but API keys or subscription keys may also be required.

Martini implementation pattern

Martini implementation pattern: place client secrets, API keys, tenant values, token URLs, audiences, and scopes in protected environment configuration. The workflow obtains or applies the required credential, sends only the necessary headers, and categorizes authentication failures separately from transaction validation or service errors.

Implementation sequence

Confirm the product-specific authentication and permission model
Store credentials and tenant configuration in protected environment settings
Obtain or configure the required access token or API key
Apply authentication to the ONESOURCE request
Capture safe correlation data without logging secrets
Rotate credentials and retest before production changes

Common Thomson Reuters ONESOURCE integration patterns

Pattern 1: Calculate tax during order processing

When to use this pattern

Use this pattern when an e-commerce, ERP, CRM, or order-management application requires tax before order confirmation or fulfillment. The workflow should include the transaction type, addresses, customer status, product classifications, amounts, discounts, freight, and other taxable components.

Integration direction
Salesforce
Martini
Thomson Reuters ONESOURCE
Example Mapping
Thomson Reuters ONESOURCE FieldCanonical FieldTarget Field
transactionTypedocumentTypeTransaction.type
shippingAddressdestinationAddressTransaction.shipToAddress
lineItems[].amountlineAmountTransaction.lines[].amount
productCodeproductClassificationTransaction.lines[].product
Martini implementation pattern

Martini receives the order through an API or workflow trigger, validates required tax inputs, maps and enriches the payload, calls the ONESOURCE determination API, and maps tax results back to the originating application. Stable references, timeout handling, and response correlation prevent ambiguous retries from creating duplicate tax requests.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Validate invoice and credit memo tax

When to use this pattern

Use this pattern when an ERP or billing platform needs tax calculation or validation at invoice or credit-memo posting. It is appropriate where final shipment destinations, discounts, freight, or document adjustments can change the tax outcome after the original order calculation.

Integration direction
NetSuite
Martini
Thomson Reuters ONESOURCE
NetSuite
Example Mapping
Thomson Reuters ONESOURCE FieldCanonical FieldTarget Field
invoiceNumberdocumentReferenceTransaction.reference
invoiceDatetaxDateTransaction.documentDate
taxTotalsourceTaxAmountreconciliation.sourceTaxAmount
taxResult.totalcalculatedTaxAmountinvoice.taxTotal
Martini implementation pattern

A scheduled or event-triggered Martini workflow reads eligible invoices or credits, submits the final document to ONESOURCE, compares the returned tax with the source amount, and updates the document or routes discrepancies for review. Validation failures are separated from transient API failures, and retries use the documented duplicate-handling behavior.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • reconciliation rules
  • error handling

Pattern 3: Reconcile order-stage and invoice-stage tax

When to use this pattern

Use this pattern when tax must be calculated before fulfillment and then recalculated or validated after shipment. It is useful for split shipments, changed destinations, final freight amounts, invoice adjustments, and other cases where the invoice does not exactly match the order.

Integration direction
SAP S/4HANA
Martini
Thomson Reuters ONESOURCE
SAP S/4HANA
Example Mapping
Thomson Reuters ONESOURCE FieldCanonical FieldTarget Field
order.idbusinessDocumentIdTransaction.reference
order.shipToorderDestinationTransaction.shipToAddress
invoice.shipTofinalDestinationTransaction.shipToAddress
taxResult.totalcalculatedTaxreconciliation.invoiceTax
Martini implementation pattern

Martini stores the order-stage correlation and tax result, receives or retrieves the final invoice, submits the final transaction to ONESOURCE, and compares both results using configurable rounding and tolerance rules. Material differences are routed to an exception process while successful results are posted to the ERP.

Martini capabilities used
  • workflow orchestration
  • data mapping
  • business rules
  • state and correlation handling
  • error handling

Pattern 4: Produce tax result and exception reporting

When to use this pattern

Use this pattern when the customer needs centralized reporting on tax calculations, rejected transactions, unresolved addresses, or reconciliation exceptions. The source may be an ONESOURCE retrieval API where available or a vendor-supported export for a product-specific reporting process.

Integration direction
Thomson Reuters ONESOURCE
Martini
PostgreSQL
Example Mapping
Thomson Reuters ONESOURCE FieldCanonical FieldTarget Field
transaction.referencedocumentReferencetax_transactions.document_reference
taxResult.jurisdictiontaxJurisdictiontax_results.jurisdiction
taxResult.amounttaxAmounttax_results.amount
processingStatuscalculationStatustax_transactions.status
Martini implementation pattern

A scheduled Martini workflow retrieves eligible results or consumes a confirmed export, normalizes tax components and exception reasons, and writes them to a reporting store. The workflow tracks pagination or file batches, preserves vendor identifiers, and retries transient failures without duplicating previously stored results.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • file processing
  • data transformation
  • database integration
  • monitoring

Applications commonly integrated with Thomson Reuters ONESOURCE

ONESOURCE can be positioned as the tax-determination or tax-compliance service within an enterprise transaction flow. The following named applications are realistic integration targets; the exact supported flow depends on the application APIs, the licensed ONESOURCE module, and the customer’s tax architecture.

Application Scenario Direction Martini Pattern
Salesforce Calculate or validate tax for quotes, orders, subscriptions, or invoice-related processes managed in Salesforce workflows. Salesforce → Martini → Thomson Reuters ONESOURCE Martini receives Salesforce transaction data through an API or workflow trigger, maps customer, address, product, and amount fields to the ONESOURCE transaction model, submits the determination request, and returns the tax result or exception to Salesforce.
SAP S/4HANA Determine and validate indirect tax for sales orders, deliveries, invoices, and credit memos. SAP S/4HANA → Martini → Thomson Reuters ONESOURCE A Martini workflow consumes the relevant SAP business document, applies transaction and jurisdiction rules, calls the provisioned ONESOURCE REST API, and maps tax amounts, rates, jurisdictions, and statuses back to SAP.
Oracle Fusion Cloud ERP Support tax calculation for receivables, order management, procurement, and financial transactions. Oracle Fusion Cloud ERP → Martini → Thomson Reuters ONESOURCE Martini orchestrates document retrieval, ONESOURCE tax determination, response normalization, and update delivery to Oracle while preserving correlation identifiers for reconciliation.
NetSuite Apply external tax determination to sales orders, invoices, cash sales, and credit memos. NetSuite → Martini → Thomson Reuters ONESOURCE Martini receives or retrieves NetSuite transaction data, maps tax-sensitive fields and line items, invokes ONESOURCE, and writes the calculated tax and processing status back to the originating transaction.
Microsoft Dynamics 365 Finance Support tax calculation for sales, purchasing, invoicing, and financial posting workflows. Microsoft Dynamics 365 Finance → Martini → Thomson Reuters ONESOURCE A Martini workflow consumes Dynamics transaction events or API responses, transforms the payload into the ONESOURCE schema, applies validation and retry rules, and returns tax results or exception details to Dynamics.
Shopify Calculate or validate tax for order and checkout-related transaction data where the merchant architecture permits external tax determination. Shopify → Martini → Thomson Reuters ONESOURCE Martini receives eligible Shopify order data, enriches it with tax-relevant addresses and product classifications, calls ONESOURCE, and sends the result to the permitted Shopify or downstream order-processing endpoint.
Zuora Determine tax for subscription invoices, usage charges, amendments, and credits. Zuora → Martini → Thomson Reuters ONESOURCE Martini processes Zuora billing documents, maps subscription and charge lines to ONESOURCE transactions, handles synchronous responses or confirmed batch flows, and returns tax results for invoice finalization.
Workday Integrate tax results with financial, billing, or expense-related processes where ONESOURCE is part of the enterprise tax architecture. Workday → Martini → Thomson Reuters ONESOURCE Martini coordinates supported Workday API or file exchanges with ONESOURCE determination, normalizes results, and delivers approved tax data or exception reports to the relevant Workday process.

How to build a Thomson Reuters ONESOURCE integration in Martini

Objective

Establish the product-specific ONESOURCE connection and verify the customer’s module, tenant, environment, API version, permissions, and authentication requirements.

Instructions in Martini

  • Confirm the provisioned ONESOURCE product and API specification
  • Configure the environment-specific base URL, tenant values, scopes, and permissions
  • Store OAuth credentials, API keys, and secrets in protected environment configuration
  • Test authentication separately from transaction processing

Objective

Select the event, API request, schedule, or confirmed file arrival that should start the integration workflow.

Instructions in Martini

  • Use an API-triggered workflow for synchronous tax determination
  • Use a scheduler for invoice validation, reconciliation, or reporting
  • Use a vendor callback only when the specific module documents it
  • Define the source document eligibility and idempotency key

Objective

Receive or retrieve the source transaction and collect all fields needed for tax determination, including addresses, products, dates, amounts, and exemption information.

Instructions in Martini

  • Retrieve the complete source document and required master data
  • Include origin, destination, billing, and service-location addresses where applicable
  • Collect line quantities, prices, discounts, freight, currencies, and product classifications
  • Reject incomplete payloads before calling ONESOURCE

Objective

Coordinate validation, enrichment, ONESOURCE invocation, response handling, and downstream updates in a maintainable Martini workflow.

Instructions in Martini

  • Separate request preparation, API invocation, response mapping, and persistence into clear workflow stages
  • Record correlation and vendor request identifiers
  • Apply timeouts and distinguish transient failures from validation errors
  • Use queueing or scheduled processing when throughput requires it

Objective

Convert source-system documents into the module-specific ONESOURCE model and normalize returned tax components for downstream systems.

Instructions in Martini

  • Map the confirmed Transaction or Document structure
  • Transform address roles, product classifications, monetary values, and date formats
  • Preserve line-level and document-level tax values
  • Apply documented rounding and tax-inclusive or tax-exclusive rules

Objective

Enforce tax-process rules such as eligibility, exemption handling, duplicate prevention, reconciliation tolerances, and exception routing.

Instructions in Martini

  • Validate required tax and jurisdiction fields
  • Use stable document references for duplicate detection
  • Compare order-stage and invoice-stage results where required
  • Route invalid addresses, unsupported classifications, and material variances for review

Common Thomson Reuters ONESOURCE data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
TransactionRepresents a sale, purchase, invoice, credit, return, or other business event submitted for tax determination.SAP S/4HANA, Oracle Fusion Cloud ERP, NetSuite, Microsoft Dynamics 365 Finance, SalesforceMartini maps the source document into the module-specific ONESOURCE transaction schema, adds correlation and idempotency references, submits it, and propagates the result.
Line or line itemRepresents an individual product or service item with quantity, amount, product code, and sourcing information.ERP, billing, commerce, and order-management applicationsMartini transforms line collections, applies amount and quantity rules, maps product classifications, and preserves line-level tax results for reconciliation.
Tax or tax resultContains calculated tax associated with a transaction or line, including jurisdiction, tax type, rate, and amount.ERP, billing, finance, data warehouse, and reporting platformsMartini normalizes tax components, handles decimal and rounding requirements, and writes the result or exception to the originating and downstream systems.
AddressProvides origin, ship-from, ship-to, bill-to, or service-location data used for sourcing and jurisdiction determination.ERP, CRM, commerce, order management, and customer master systemsMartini validates and maps address roles and fields, applies source-system defaults where approved, and routes incomplete or invalid addresses for correction.
ProductIdentifies a product or service used for taxability, product classification, and tax treatment.Product catalogs, ERP, commerce, billing, and subscription platformsMartini maps source product codes and classifications to the ONESOURCE request and applies business rules for missing or unsupported tax classifications.
DocumentRepresents an invoice, credit, or other fiscal document in modules that use Document as the top-level object instead of Transaction.ERP, billing, finance, compliance, and reporting platformsMartini validates whether the provisioned API uses Document or Transaction, then maps document headers, lines, references, and tax results consistently.

Authentication and security considerations

Product-specific authentication

ONESOURCE authentication depends on the licensed module, tenant, and API product. OAuth 2.0 and client credentials should be evaluated for modern APIs, while API keys, subscription keys, application identifiers, scopes, and tenant permissions may also be required.

Credential protection

Store client secrets, access tokens, API keys, tenant identifiers, and environment-specific values in protected Martini configuration or secrets. Do not embed credentials in workflows or write tokens to diagnostic logs.

Data protection

Tax payloads may contain customer, address, financial, and registration information. Restrict access, minimize retained payloads, protect logs, and use separate test and production credentials and endpoints.

Operational considerations for Thomson Reuters ONESOURCE integrations

Throughput and rate limits

Confirm ONESOURCE quotas, concurrency limits, and request-size constraints. Use controlled concurrency, queueing, scheduling, and exponential backoff for transient failures or throttling.

Idempotency and reconciliation

Use stable transaction or document references and verify the API’s duplicate-handling behavior before retrying an ambiguous timeout. Reconcile order-stage and invoice-stage tax results where shipment, freight, discounts, or rounding can change the outcome.

Pagination and batch processing

If the selected API exposes list or reporting operations, implement its documented cursor, continuation-token, or page-size behavior. Do not assume offset pagination. For files or batch jobs, track file identifiers, processing status, accepted records, and rejection reports.

Schema and testing

Protect mappings against new tax types, jurisdictions, required fields, precision changes, and API-version retirement. Use contract tests in the ONESOURCE test environment and validate line-level versus document-level rounding before production release.

Monitoring

Record safe correlation IDs, vendor request IDs, processing status, latency, and categorized errors. Monitor failed validations, throttling, authentication failures, and reconciliation variances without logging sensitive payloads unnecessarily.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini provides a maintainable workflow layer between ONESOURCE and ERP, billing, commerce, CRM, or reporting applications. The same integration can coordinate validation, tax determination, reconciliation, and exception routing without duplicating logic in every source system.

Reusable transformation

Martini maps different source document models into the customer-specific ONESOURCE schema and normalizes tax results for multiple targets. Reusable workflows and services can preserve consistent rules for addresses, products, amounts, rounding, and identifiers.

Operational control

Compared with isolated scripts, Martini provides structured triggers, API orchestration, scheduling, error handling, monitoring, protected configuration, and controlled deployment. These capabilities support retries, reconciliation, testing, and future API-version changes.

API-led access

Martini can expose a controlled API façade for tax determination while keeping ONESOURCE credentials and vendor-specific details behind the integration boundary. This allows consuming applications to use a consistent enterprise contract even when ONESOURCE module details vary.

Frequently asked questions

How can Thomson Reuters ONESOURCE be integrated with enterprise systems?

ONESOURCE Indirect Tax products are commonly integrated through provisioned REST APIs that receive transaction data and return tax results. Depending on the module, selected compliance or reporting workflows may also use batch or file exchange. Authentication, payloads, endpoints, and available operations vary by product, region, tenant, and contract.

Can Martini integrate with Thomson Reuters ONESOURCE?

Yes. Martini can integrate with the specific ONESOURCE APIs provisioned for a customer by consuming REST endpoints, applying the required authentication, mapping transaction and tax data, orchestrating workflows, and returning results to ERP, billing, commerce, or other applications. Supported file exchanges can also be implemented when documented for the module.

Do I need a connector to integrate Thomson Reuters ONESOURCE with Martini?

No. A dedicated ONESOURCE connector is not required. Martini can use the vendor’s documented REST APIs, authentication methods, and confirmed file or callback mechanisms, with workflows handling transformation, business rules, retries, and downstream updates.

Is there any extra Lonti cost to integrate Thomson Reuters ONESOURCE with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate ONESOURCE. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Thomson Reuters, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Thomson Reuters ONESOURCE integration method should be used?

Use the customer-specific ONESOURCE REST API for real-time tax determination when it is provisioned. Evaluate documented batch or file mechanisms for compliance and reporting workloads. GraphQL and current SOAP support were not confirmed, and direct database access should not be assumed.

Does Thomson Reuters ONESOURCE support webhooks or outbound callbacks?

A general webhook framework for the ONESOURCE portfolio was not confirmed. Individual modules may expose callbacks or notifications for selected asynchronous operations, so event types, delivery, signing, retry behavior, and payloads must be verified before use.

How does Martini synchronize and transform ONESOURCE tax data?

Martini can receive or retrieve orders, invoices, credit memos, or supported exports, map transaction, line, address, product, and document fields to the ONESOURCE model, and normalize tax results for downstream systems. Workflows can also maintain correlation identifiers, reconciliation state, and exception outcomes.

How are errors, retries, and duplicate tax requests handled?

Martini can separate authentication, validation, jurisdiction, throttling, network, and vendor processing errors. Transient failures can use controlled backoff, while invalid data is routed for correction. Stable transaction or document references and the ONESOURCE duplicate-handling behavior should be used to prevent unsafe resubmission after ambiguous timeouts. Martini can also expose an API façade for controlled access to the integration workflow.

Related Martini documentation

APIs

Workflows

Transformation

Security

Operations

Integrate Thomson Reuters ONESOURCE with Martini

Use Martini to connect the ONESOURCE capabilities provisioned for your organization with enterprise applications through secure APIs, orchestrated workflows, data mapping, and controlled automation.

EXPLORE MARTINI
BOOK A DEMO