Shared Transactions Integrating with Third Party Software
Overview
If you're connecting Shared Transactions to a third-party AP provider (Stampli, RAMP, and similar) that pulls fields from NetSuite and sources them into its own system, this article covers the one piece of setup that makes that work: a small set of custom fields.
Does this apply to you?
Use this setup only if both of these are true:
- You use 1:1 allocations - moving a transaction to a different subsidiary, department, class, or location than where it was originally coded (or any combination of these).
- Your third-party provider needs to read and write list/record fields.
If you allocate using Shared Transactions templates instead, you can skip the custom-field setup below. The template field is already a list/record field, so your provider can source into it as-is - no custom fields needed. Point your third-party team at whichever one you use:
- Shared Transaction Template (Line) - ID
custcol_nta_allocation_template_line- for allocating individual transaction lines. - Shared Transaction Template (Body) - ID
custbody_nta_allocation_template_body- for applying a single template to the whole transaction.
What you're setting up
Native Shared Transactions line fields are stored as integer fields (a NetSuite system requirement), which third-party providers can't read or write - they need list/record fields. The workaround: you create a list/record custom field for each standard segment you want to allocate on, using a specific set of field IDs. When the IDs match exactly, our scripts automatically copy the values your provider sends into the native allocation fields, and Shared Transactions works as it normally does.
There are three steps, plus one optional one:
- Create the custom fields.
- Give the field IDs to your third-party team.
- (Optional) Show the fields on your NetSuite forms.
Step 1 - Create the custom fields
You need permission to create custom transaction line fields in NetSuite. Go to Customization > Lists, Records, & Fields > Transaction Line Fields and create one field per standard segment you want to allocate on.
You don't have to create all five. There are five possible segments (subsidiary, department, class, location, account); set up only the ones you plan to allocate on. If you'll never allocate on location, for example, skip that field.
The field IDs must match exactly.
If you do not use the exact IDs in the table below, the integration will not work for that field. Everything else (the label, for example) you can adjust to suit your account.
| Label (example) | ID | Type | List/Record | Applies To | Access |
| [Provider Name] Shared Transaction Subsidiary (Line) | _nta_ng_subsidiary | List/Record | Subsidiary | Expense, Purchase Item, Sale Item, Journal, Expense Report | Default Access Level = Edit; Default Level for Search/Reporting = Edit (or grant specific access to the roles that need it) |
| [Provider Name] Shared Transaction Department (Line) | _nta_ng_department | List/Record | Department | Expense, Purchase Item, Sale Item, Journal, Expense Report | Default Access Level = Edit; Default Level for Search/Reporting = Edit (or grant specific access to the roles that need it) |
| [Provider Name] Shared Transaction Class (Line) | _nta_ng_class | List/Record | Class | Expense, Purchase Item, Sale Item, Journal, Expense Report | Default Access Level = Edit; Default Level for Search/Reporting = Edit (or grant specific access to the roles that need it) |
| [Provider Name] Shared Transaction Location (Line) | _nta_ng_location | List/Record | Location | Expense, Purchase Item, Sale Item, Journal, Expense Report | Default Access Level = Edit; Default Level for Search/Reporting = Edit (or grant specific access to the roles that need it) |
| [Provider Name] Shared Transaction Account (Line) | _nta_ng_account | List/Record | Account | Expense, Purchase Item, Sale Item, Journal, Expense Report | Default Access Level = Edit; Default Level for Search/Reporting = Edit (or grant specific access to the roles that need it) |
What happens after you add the fields
As soon as these fields exist, our scripts hide the native Shared Transactions line-level allocation fields and show only your custom fields. This is expected behavior, not a problem - it prevents a data mismatch between the two sets of fields and keeps your forms uncluttered. The scripts still copy the values over to the native fields behind the scenes. If you have CSV import templates or memorized transactions that filled in the native fields, repoint them at your custom fields, since those fields are now hidden.
Step 2 - Give the field IDs to your third-party team
Your provider's administrators or implementation team need the IDs of the fields you created. Give them the IDs from your account, or just share the table above - that's everything they need to pull from and post to the right fields.
Step 3 - Show the fields on your NetSuite forms (optional)
The scripts source from your custom fields whether or not the fields appear on your forms, so this step is optional. Show them if you want to see what your third-party system sends into NetSuite and what our scripts copy over to the native Shared Transactions fields.
Two ways to do it:
- Go to Customization > Forms > Transaction Forms and edit your preferred journal entry (or other transaction) form.
- Or use Save and Apply to Forms as you create each custom field.
We recommend exposing both the custom fields and the native Shared Transactions fields while you implement, then hiding the custom fields once you're live so you don't see the same data twice.
Limitations
Shared Transactions can't reformat or reconfigure data after it arrives in NetSuite - it works with whatever the third party sends. If incoming data is structured in a way Shared Transactions can't use, work with your provider to correct it on their side before it reaches NetSuite.
