# SAP Concur NetSuite integration

*SAP Concur → NetSuite*

**In short:** A SAP Concur to NetSuite integration turns every approved expense report into a NetSuite transaction - a vendor bill for out-of-pocket spend, a card-liability clearing entry for company card charges - coded to the right subsidiary, department, class, and project, with reclaimable VAT split from the gross. Master data flows the other way so submitters can only pick coding NetSuite accepts, and payment confirmations flow back so employees see Paid. Done properly it is an idempotent pipeline, not a monthly CSV import.

## What a SAP Concur to NetSuite integration actually does

SAP Concur is where spend gets captured and approved. An employee books a trip, swipes the corporate card, photographs a restaurant receipt, allocates it to a project, and submits a report that runs through policy checks, VAT logic, and manager approval. NetSuite is where that same spend has to become accounting: a posted liability against the right subsidiary, coded to a department, class, location, and project, with recoverable input tax separated from the gross, and the employee actually paid in the next AP run.

Between approved in Concur and posted in NetSuite sits work a lot of finance teams still do by hand every month. Someone pulls the accounting extract, reshapes columns in a spreadsheet, guesses which NetSuite employee record matches which Concur user, imports a CSV, and then chases the lines NetSuite rejected because a department was inactive or the period was already locked. A SAP Concur to NetSuite integration removes that step: every report that reaches the extracted state in Concur becomes exactly one posted transaction in NetSuite, master data flows back the other way so submitters can only pick coding NetSuite accepts, and the payment confirmation returns to Concur so nobody has to answer a status email.

## What data moves

| SAP Concur object or event | Becomes in NetSuite | Notes |
| --- | --- | --- |
| Approved, extracted expense report (employee-paid) | Vendor bill against the employee as vendor, or a NetSuite expense report record | One line per expense entry, coded to the mapped expense account |
| Company card transaction on a report | Credit card charge or journal clearing the card liability account | Never reimbursed to the employee; driven by the Concur payment type |
| Expense entry allocations | Department, class, location, project on the transaction line | Concur percentage splits resolved to amounts, with rounding assigned deterministically |
| Reclaimable VAT on an entry | Tax code and tax detail on the line | Domestic and foreign VAT split from the gross so input tax stays recoverable |
| Cash advance | Employee advance or prepayment applied against the report | Has to exist in NetSuite before the report that consumes it |
| Concur Invoice payment request | Vendor bill against the NetSuite vendor, matched to a purchase order where used | Concur Invoice module only |
| Receipt image | File cabinet attachment on the posted transaction | Where audit or retention rules want the document with the booking |
| NetSuite payment of the bill | Payment confirmation written back to Concur | Report status flips to paid, which stops most status enquiries |

In the reverse direction, NetSuite employees, vendors, subsidiaries, departments, classes, locations, projects, and the relevant part of the chart of accounts are pushed into Concur as list items and expense-type mappings. That reverse flow is what makes the forward flow post on the first attempt.

## The details that break naive exports

A monthly extract and a CSV import get the happy path working and leave the expensive cases on the AP desk:

- **Employee identity.** The Concur login or employee ID and the NetSuite employee internal ID are different keys, and neither survives a reorganisation on its own. Joiners, leavers, and name changes have to resolve to a stable mapping, or a report posts against the wrong person or nobody at all.
- **Payment type is not a detail.** Employee-paid, company card, and company-paid entries create three different postings. Treat them alike and you either reimburse an employee for something the company already paid or leave the card liability unreconciled against the statement feed.
- **Three currencies in one report.** The expense currency, the Concur reimbursement currency, and the NetSuite subsidiary base currency are rarely the same. Concur fixes a rate at submit, NetSuite values the posting date. The delta belongs in an FX account, not in the amount the employee receives.
- **VAT and reclaim.** Posting the gross is the fast way to lose input tax deduction. Domestic VAT, foreign VAT eligible for refund, and non-deductible shares such as parts of hospitality spend each need the correct NetSuite tax code, which depends on your nexus setup and on whether you run SuiteTax or the legacy engine.
- **Subsidiary derivation in OneWorld.** The posting subsidiary comes from the employee or the allocation, not from a default. Cross-entity charges need an agreed intercompany treatment rather than a silent misposting.
- **Closed periods.** Reports approved on the second of the month routinely belong to the previous one, and NetSuite refuses a posting into a locked period. That needs an explicit posting-date rule and a queue for late arrivals, not a hard failure.
- **Governance and month-end spikes.** NetSuite enforces concurrency limits and request governance, and RESTlets time out. A close-week batch of several thousand lines has to be chunked, throttled, and retried with backoff instead of half-posting.
- **Partial failures and idempotency.** One line with an inactive department makes NetSuite reject the whole record, so we validate line by line before submit and surface rejects as visible work items. And every report maps to exactly one NetSuite transaction through a stable external ID, driven by the Concur workflow state rather than a last-modified timestamp, which is the difference between a safe re-run and booking March twice.

## How we build and run it

We treat this as a pipeline, not a scheduled export. Reports are picked up as they reach the extracted state in Concur, validated against live NetSuite master data, transformed into your agreed coding, and written through SuiteTalk REST or a RESTlet, whichever your NetSuite administrator prefers to support. Master data moves the other way on a delta schedule, and payment confirmations are written back to Concur once NetSuite actually pays.

The pipeline is idempotent. Each Concur report carries a stable identifier that becomes the external ID on the NetSuite transaction, so a retry, a replay, or a re-run after an outage never creates a second vendor bill. It runs on cloud-native, fully EU-hosted AWS infrastructure, so employee and transaction data does not leave the EU, which keeps the DPA / AVV and your GDPR obligations straightforward.

Then we keep it running. Monitoring, alerting, incident response, and watching for Concur API deprecations and NetSuite release changes are our responsibility under contract, at a fixed scope agreed up front. Your AP team stops reconciling a spreadsheet during close week.

## When this integration is worth building

If a handful of people submit expenses in a single entity and a single currency, the Concur extract and a monthly import are genuinely fine, and we will say so. The integration earns its place when report volume makes manual coding a recurring job, when OneWorld subsidiaries and foreign VAT make the mapping too intricate to hold in a spreadsheet, when corporate card liability never quite reconciles, or when the close already slips because someone is fixing a failed import instead of closing the books.

## Frequently asked questions

### Do you take the data out of Concur as a file extract or through the API?

Through the API wherever your Concur entitlements allow it. We read approved reports and their entries through the Expense Report APIs and post results back through the financial integration and payment confirmation services, so every report has a per-document status instead of a file that either imported or did not. Where your Concur edition or your existing process is built around the Standard Accounting Extract, we consume that file instead and keep the same idempotency and error handling around it.

### Should expense reports land in NetSuite as vendor bills or as NetSuite expense reports?

It depends on how you pay employees. If reimbursements go out through the normal AP payment run, a vendor bill with the employee set up as a vendor keeps the liability, the payment, and the remittance in one familiar workflow. If reimbursements run through payroll or through NetSuite Expense Management, the native expense report record fits better. We decide this once with your controller, because it drives vendor setup, approval routing, and how payments are confirmed back to Concur.

### How do you handle corporate card transactions versus out-of-pocket spend?

They are two different postings and confusing them doubles your liability. Concur payment types tell us which is which: employee-paid entries become a reimbursable liability to the employee, while company card entries clear the corporate card liability or clearing account that the card statement feed also posts against. Personal expenses charged to a company card get their own treatment as an employee receivable rather than an expense.

### Does it work with NetSuite OneWorld, multiple subsidiaries, and foreign currency?

Yes, and that is usually the hardest part of the mapping. The posting subsidiary is derived from the employee record or the allocation rather than assumed, so a report from a German entity does not land in the US books. Concur converts to the reimbursement currency at submit, NetSuite values the transaction against the subsidiary base currency on the posting date, and we book the difference to a defined FX account instead of quietly changing what the employee gets paid.

### Who operates it after it goes live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Concur deprecates an API version or NetSuite changes a record schema in a release upgrade, that is our problem to catch and fix, not a failed batch your AP team finds on the last day of the close. You get a named owner, alerting, and an SLA rather than an import script somebody has to remember to run.

## Related integrations

- [SAP Concur ↔ DATEV](https://seamless.engineering/integrations/sap-concur-datev/): SAP Concur DATEV integration
- [Coupa ↔ NetSuite](https://seamless.engineering/integrations/coupa-netsuite/): Coupa NetSuite integration
- [Amazon ↔ NetSuite](https://seamless.engineering/integrations/amazon-netsuite/): Amazon NetSuite integration
- [BigCommerce ↔ NetSuite](https://seamless.engineering/integrations/bigcommerce-netsuite/): BigCommerce NetSuite integration
- [Magento ↔ NetSuite](https://seamless.engineering/integrations/magento-netsuite/): Magento NetSuite integration
- [NetSuite ↔ HubSpot](https://seamless.engineering/integrations/netsuite-hubspot/): NetSuite HubSpot integration

## Browse by system

- [All SAP integrations](https://seamless.engineering/integrations/sap/)
- [All NetSuite integrations](https://seamless.engineering/integrations/netsuite/)

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact