Overview

If you're connecting Shared Payments 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.

What you're setting up

The native Shared Payments fields on your transactions (subsidiary and bank account) 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 body field for each Shared Payments field, using a specific set of field IDs. When the IDs match exactly, our scripts automatically copy the values your provider sends into the native Shared Payments fields, and Shared Payments works as it normally does.

There are two steps, plus one optional one:

1. Create the custom fields.
2. Give the field IDs to your third-party team.
3. (Optional) Show the fields on your NetSuite forms.

Step 1 - Create the custom fields

You need permission to create custom transaction body fields in NetSuite. Go to Customization > Lists, Records, & Fields > Transaction Body Fields and create two fields: one for subsidiary and one for bank account.

A few things to know about field setup:

• The ID column shows the required suffix. When you create the field, NetSuite prepends custbody automatically (so the full ID becomes custbody_nta_ng_shared_pmt_sub, for example). Don't change the suffix, or the system won't recognize the field.
• The Bank Account field is only necessary if you have the "Initiate Shared Payment from Source" setting enabled.
• The subsidiary field must be filled in on the transaction before the bank account field will appear.

What happens after you add the fields

As soon as these fields exist, our scripts use them instead of the native Shared Payments fields and hide the native (integer) fields from the form. 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 move the values through to the native fields behind the scenes:

• On save, the values from your custom fields are written through to the native fields, so the Shared Payments process runs as normal.
• On load, if the transaction already has a Shared Payments subsidiary set, your custom field is pre-populated with the correct value.
• On any form where these custom fields are not present, behavior is unchanged - the system falls back to the standard native field behavior.

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 Payments fields.

Two ways to do it:

• Go to Customization > Forms > Transaction Forms and edit your preferred vendor bill (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 Payments fields while you implement, then hiding the custom fields once you're live so you don't see the same data twice.

Limitations