Shared Transactions Tips and Troubleshooting

Overview

This article collects practical tips for running Shared Transactions and fixes for the issues we see most often. If an allocation journal didn't generate, a Shared Transactions journal won't save, or a CSV import isn't allocating, start here. For a specific error message, how to read the script execution logs, or a reference of the scripts behind Shared Transactions, see Shared Transactions Common Errors and Fixes.

Tips

Shared Transactions allocates the GL impact of the line it sits on.

This is the core design principle, and it explains most "why didn't this allocate the way I expected" questions. The allocation follows wherever the expense actually hits the GL - so for items set to Generate Accruals, the GL impact (and the allocation) happens at the Item Receipt, not the Bill. See Shared Transactions Allocation GL Impact and Shared Transactions Item Receipts.

An allocation journal is only created once the source transaction hits the GL.

A transaction that is still Pending Approval, unapproved, or Cancelled has not posted, so no allocation journal exists yet. This is by design, not a failure - approving the transaction (or editing and saving it) triggers the allocation.

Confirm the transaction type is enabled for allocation.

Shared Transactions only allocates the transaction types selected under Deployed To Transactions in Netgain > Setup > System Setup.

Segments and entities have to be valid in the destination subsidiary.

A template or line that allocates a department, class, location, account, or entity into another subsidiary only works if that record is shared with the destination subsidiary. The most common setup miss is leaving Include Children unchecked on the subsidiary record. These validation failures are the single biggest cause of allocations not generating - see Shared Transactions Common Errors and Fixes.

Let NetSuite generate your representing entities.

When your intercompany accounts are set to eliminate, Shared Transactions uses the system-generated representing vendor/customer (the IC- entities created from Setup > Company > Subsidiaries > Generate Representing Entities). Manually-created or duplicate intercompany entities cause the wrong one to be tagged on the due-to/due-from lines - inactivate them so the system-generated entity is used. See Shared Transactions Intercompany Setup.

A line-level segment overrides the template on that line.

If a line has both a Shared Transaction Template and a Shared Transaction Subsidiary, Department, Class, or Location populated, the line-level segment wins and the template won't apply. Conversely, populating any of those line fields is enough to trigger an allocation on its own - so clear them on lines you don't want allocated.

Editing and saving a source transaction re-runs its allocation.

That's the manual re-trigger for one transaction; to re-trigger in bulk, schedule NTA | Transaction Updates | MR (see the script reference in Shared Transactions Common Errors and Fixes). Re-runs flow only forward - changing a sourcing record or template doesn't correct allocation journals already generated. See Shared Transactions - Impacts of Editing a Source Transaction.

Troubleshooting

Note

For a specific error message, use the lookup in Shared Transactions Common Script Errors and Fixes. The table below covers behavior that isn't tied to a single error string.

Issue	What to check
An allocation journal didn't generate for a transaction	The most common case, usually a setup cause. Check: The source transaction is approved and posted - Pending Approval, unapproved, or Cancelled transactions don't allocate. Approve it, or edit and save it, to re-trigger. The transaction type is selected in Deployed To Transactions (Netgain > Setup > System Setup) Check the Script Execution Logs for an error on save - most non-allocations are a segment/entity validation error; look it up in Common Script Errors and Fixes. Try rerunning the allocation by "editing" and re-saving the transaction or run NTA \| Transaction Updates \| MR.
Shared Transactions created a duplicate allocation journal	This happens when a source transaction's link to its allocation journal is broken (for example, the allocation journal was deleted) while the Shared Transaction line fields are still populated - the script sees the values, finds no linked journal, and creates a new one. Check: If you re-ran NTA \| Transaction Updates \| MR after manually creating allocation journals, set a Minimum Date on the deployment so it doesn't rebuild transactions you already handled. Whether the Delete Original Allocation Transaction When Updating setting (Netgain > Setup > System Setup) matches your intent: when on, editing the source deletes and recreates the allocation journal; when off, it edits the existing one in place (a few NetSuite-limited cases still force a delete-and-recreate). To stop allocating a line entirely, clear its Shared Transaction fields - leaving them populated re-triggers creation.
Saving a large allocation times out ("Script Execution Time Exceeded")	The transaction has too many lines for the real-time (user-event) script. Check: Lower the Map Reduce Allocation Script Threshold (Netgain > Setup > System Setup) so transactions above that line count are handled by the Map/Reduce script instead. Then edit and save to retrigger. Split very large transactions into smaller ones. Map/Reduce allocation is slower than real-time but avoids the timeout.
CSV import "succeeds" but the bill/allocation is missing	The record imports but the allocation runs in a different script context than the UI. Check: The destination subsidiary is on the representing-entity vendor's Subsidiary subtab (the "inactive/not available" cause). Map the native Shared Transaction line fields and use internal IDs (line-level Subsidiary/Department are integer fields, so names won't import). After import, run NTA \| Transaction Updates \| MR to create the allocation journals; an "AFTERSUBMIT processing failed" message on import is a known quirk and the catch-up script completes the allocation.
Ramp (or another third-party integration) transactions aren't allocating	Ramp and similar tools error inside their own scripts before the real-time allocation script fires, so the allocation never starts. For these, use the Sync Override script rather than the standard catch-up: Deploy and schedule NTA \| Transaction Sync Override \| MR - it targets transactions that use the integration's override fields and weren't allocated. In the deployment Parameters, check the segments the account doesn't use (the inactive segments listed under Netgain > Setup > System Setup), and set a Minimum Date if you have prior manual allocations. Run it once and confirm no segment errors, then schedule it nightly during off-peak hours (around 4:30 AM is a good default).
Shared Transaction columns don't appear on the transaction line	A form or integration issue. Check: The fields are set to Show on the custom transaction form you're using (NetSuite CSV import only maps fields shown on the selected form). If you use Ramp (or another third-party integration), its 1:1 custom columns override the native Shared Transaction columns - use the Ramp columns; they produce the same result. For CSV: select the Standard form or a form with the fields exposed in the import mapping.
A 1:1 allocation field shows as free text instead of a dropdown	The script that renders the field as a select list isn't running. Check: The NTA \| Transaction \| UE script is deployed (Customization > Scripting > Script Deployments).
The vendor/entity isn't copied to the destination side of the AICJE	Driven by your sourcing and intercompany setup. Check: Whether the intercompany payable and receivable accounts are elimination accounts - the representing entity is tagged on the due-to/due-from lines only when they are. The Ignore Original Transaction Line Value checkbox on the Entity/Vendor sourcing record - unmark it to carry the original line value onto the allocation. Sourcing-record changes apply going forward only - re-trigger older entries to correct them. For employees: an Advanced Intercompany Journal can't hold an Employee as the entity (native NetSuite limit). Use a custom transaction line field to carry the employee name instead. See Shared Transaction Sourcing.
The wrong intercompany entity is tagged on the due-to/due-from lines	Usually duplicate or manually-created intercompany entities. Shared Transactions has no setting for a default IC entity, so it uses the first valid one it finds. Check: Inactivate duplicate or manually-created IC vendors/customers so only the system-generated `IC-` entity remains. Confirm representing entities were generated from the Subsidiary record.
Native amortization on an allocated bill isn't allocated	Shared Transactions and NetSuite's native Amortization can't be layered on the same bill - allocations don't flow to the amortization journals. Recommended approach: Disable Use Custom Transactions (Netgain > Setup > System Setup > System Features). Allocate the bill, then create the amortization from the journal the allocation produced.
A custom segment doesn't appear on the allocation lines	The field has to be a true custom segment with a sourcing record. Check: Native Expense Category on Expense Reports isn't a segment and doesn't post to the GL impact - build a custom segment for it first. Create the Shared Transaction Sourcing record for the segment per Shared Transaction Sourcing.
The Shared Transaction Subsidiary line shows an internal ID instead of the subsidiary name	Cosmetic. The line field stores an integer; the name is rendered separately. The ID can show when the transaction is voided/cancelled, modified by a non-Shared-Transactions workflow or script, or opened during high system load. It usually self-corrects the next time the transaction is opened in the UI. If it persists on an active transaction, contact support.

Frequently Asked Questions

Question	Answer
Which transactions can Shared Transactions allocate?	The standard license supports Bills, Journals, Invoices, Checks, Credit Card Charges, Credit Card Refunds, Expense Reports, Purchase Orders, Vendor Credits, and Sales Orders. Each type still has to be added to Deployed To Transactions in Netgain > Setup > System Setup before it will allocate.
Why isn't the Allocate Expense button showing on my bill?	The Allocate Expense button only appears once the bill is saved and you're in View mode. It won't show while you're editing.
Can I import allocation templates and allocated transactions by CSV?	Yes. Templates import as two native CSV imports - first the Shared Transaction Template records, then the Shared Transaction Allocation records. See Shared Transactions Mass Uploading Allocation Templates.
Can I layer NetSuite's native Amortization on an allocated bill?	No. Allocations don't flow to the amortization's journal entries, so the amortization journals won't be allocated. Best practice is to disable Use Custom Transactions (Netgain > Setup > System Setup > System Features), allocate the bill, then create the amortization from the journal the allocation created.
Do items marked for accrual allocate at the bill or the item receipt?	Shared Transactions allocates wherever the line's GL impact lands. For a non-inventory item with Generate Accruals = TRUE, the GL impact is at the Item Receipt, so the allocation happens there; with Generate Accruals = FALSE, it happens at the Bill. Allocation on item receipts for accrual items is supported on current SuiteApp versions - stay up to date if you don't see it.
Does Shared Transactions require the NetSuite intercompany framework?	If your intercompany accounts are set to eliminate, you need intercompany vendors and customers (representing entities). If your accounts are not elimination accounts, representing entities aren't required. Either way, Shared Transactions follows NetSuite's intercompany configuration, so the framework needs to be set up correctly for cross-subsidiary allocations. Note: creating intercompany customers and vendors requires the NetSuite Intercompany Framework feature (Setup > Company > Enable Features > Accounting), and once enabled it cannot be disabled - confirm with your administrator or NetSuite representative first.
Can I have separate allocation forms for journals and for vendor bills?	Not currently. NetSuite allows only one preferred form per transaction type, and Shared Transactions has no feature to work around that.
Is the bundle managed, and how do updates work?	Yes, the SuiteApp is managed. Production updates are pushed by Netgain - file a request with support to update your Production account; manual updates can be done in Sandbox by an Administrator. You can check which version your SuiteApp is on by navigating to SuiteApps > Shared Transactions > compare installed version vs latest version. Note: A version update does not re-run any allocation; trigger the catch-up script afterward if needed.

Error messages and scripts

Anything tied to a specific error message, how to read the script execution logs, and a full reference for the background scripts that run Shared Transactions all live in one place: Shared Transactions Common Script Errors and Fixes . Start there for any error or script questions.

Still Need Help?

If these steps don't resolve the issue, or you're seeing an error that isn't covered here or in Shared Transactions Common Errors and Fixes, contact Netgain support at support@netgain.tech. Include the script name, the error message and timestamp from the execution log, the source transaction, and the subsidiaries involved. Keeping your SuiteApp up to date also resolves some issues, since fixes ship in updates. To grant access for a support case, see Shared Transactions - Providing Access to NetSuite Account for Support Cases.

Was this article helpful?