Skip to main content

Managing your Sage Expense Management (SEM) and Sage Intacct integration in a multi-entity setup

How SEM connects to a multi-entity Sage Intacct company, what's supported today, and the setup we recommend for your entities.

P
Written by Product Team

Sage Expense Management (SEM) is built around a single-entity integration model: one org connected to one Sage Intacct entity (or the Top Level). This keeps user access, approval policies, and financial data cleanly scoped.

Customers typically use either one SEM org per entity with users able to belong to multiple SEM orgs or one SEM org connected at the Top Level. This page covers what’s supported, what isn’t yet, and the recommended workaround setups for multi-entity organizations.

A note on terminology

Sage Intacct and SEM describe similar concepts using different terms. To keep this page consistent, we use Sage Intacct’s terms for Intacct structures and SEM’s terms for the SEM side:

  • Top Level (Sage Intacct): The level above all entities where shared data is managed and authorized transactions can be posted to accessible entities or Locations.
    ​

  • Entity (Sage Intacct): A separately balanced business unit within a multi-entity shared company.
    ​

  • Location (Sage Intacct): A transaction dimension that belongs to one entity and identifies which entity owns a transaction line.

  • Org (SEM): One SEM account connected to either a Sage Intacct entity or the Top Level.

The key that makes multi-entity Sage Intacct setups workable with SEM today: spenders, admins, and approvers can all be members of more than one SEM org at the same time. So even though each org is scoped to one entity (or the Top Level), the same person can move between orgs that map to different entities.

Can a single SEM org be connected to multiple Sage Intacct entities?

❌ No - One SEM org can have only one Sage Intacct connection target: either one entity or the Top Level. A Top Level connection can post lines to multiple permitted entities using the Location dimension, but it is not the same as maintaining separate connections to those entities.

  • Separate SEM orgs, one per entity — the cleanest setup when entities have different dimension structures, policies, or tax requirements.

  • A single SEM org connected at the Sage Intacct Top Level — works well when entities share the same chart of accounts and dimension structure, and you want one place to manage users, cards, and policies. Employees who work across entities can be added to the org once rather than duplicated.

Best practice:

  • Dimensions and policies are consistent across entities → connect at the Top Level.

  • Dimensions, policies, or tax rules vary by entity → use a separate SEM org per entity.

Can SEM route expenses to specific Sage Intacct entities?

❗Only through the Location dimension. Sage Intacct entities cannot be imported into SEM as a separate dropdown, and SEM cannot route expenses by cardholder or card or any other parameter/dimension.

Instead, users select a Location on the expense. Sage Intacct uses the Location/Entity hierarchy to identify the entity that owns the exported line.

A Top Level connection can make Locations from multiple permitted entities available to SEM. However, Location coding alone does not guarantee cross-entity posting, the result also depends on the export type and Sage Intacct configuration.

Can I create inter-entity transactions via exports from SEM to Sage Intacct?

✅ Yes, with the right setup, and provided the integration user has permission to create journal entries and access to every entity involved.

SEM doesn’t support inter-entity transactions natively, but you can use a journal entry (JE) export workaround to automate inter-entity due-to/due-from postings.

On the SEM side, configure:

  1. Export expenses as Journal Entries, rather than as bills or expense reports.

  2. Group journal entries by report, so each report becomes one JE.

  3. Enable the single offset credit line entry setting, so each JE posts with one offsetting credit line rather than one per expense line.

  4. Import Sage Intacct Locations as a dimension, and code each expense line to the Location (entity or child location) it belongs to.

  5. Set a Default Location under Advanced Settings.

On the Sage Intacct side, this requires:

  • A multi-entity shared-company structure.

  • Basic or Advanced inter-entity account mappings configured.

  • A valid Source Entity on the journal-entry header (exported from SEM based on the Default Location).

  • A Location on every journal-entry line (exported from SEM based on the Location coded for the respective expense line item).

  • Integration-user access to all affected entities.

  • Transaction currencies and exchange rates that are valid for the affected entities.

📌 This is a configuration pattern we’ve seen work for customers. It isn’t a native SEM feature, and SEM doesn’t configure or validate the Sage Intacct side of this setup. We recommend working with your Sage Intacct implementation partner to confirm your entity, Location, and account mapping structure supports it.

How the Default Location determines inter-entity journal entries

When expenses are exported as journal entries and grouped by expense report, SEM creates:

  • Multiple debit lines, one for each expense.

  • One offsetting credit line for the total report amount.

The Default Location configured in SEM is used for:

  1. The journal entry’s header-level Source Entity.

  2. The Location on the single offsetting credit line.

Each expense’s selected Location is placed on its corresponding debit line. Sage Intacct uses each Location’s position in the Location/Entity hierarchy to determine which entity owns that line.

If an expense line belongs to an entity other than the Source Entity, Sage Intacct treats it as an inter-entity transaction. When inter-entity transactions and account mappings are configured, Intacct automatically creates the corresponding due-to and due-from lines so that every affected entity remains balanced.

Example

Assume:

  • The SEM Default Location is USA 1.

  • Therefore, USA 1 becomes the journal entry’s Source Entity.

  • The offset account, such as a corporate card liability or clearing account, belongs to USA 1.

  • The report contains expenses for both USA 1 and USA 2.

SEM exports the following journal entry:

Journal-entry line

Debit

Credit

Location/entity

Meals and Entertainment

$25

—

USA 1

Office Supplies

$25

—

USA 1

Flight to Sage Future

$150

—

USA 2

Stay in LA for Sage Future

$200

—

USA 2

Offset credit line

—

$400

USA 1

The journal-entry header identifies USA 1 as the Source Entity.

How Sage Intacct evaluates the entry

Intacct groups the journal lines by their owning entities:

Entity

Debits

Credits

Net before IET balancing

USA 1

$50

$400

$350 credit

USA 2

$350

$0

$350 debit

The two USA 1 expenses remain within the Source Entity and do not require inter-entity balancing.

The two USA 2 expenses total $350. Because USA 1 carries the corresponding credit while USA 2 carries the expense debits, Intacct recognizes that USA 1 has incurred or funded $350 of expenses on behalf of USA 2.

Using the configured inter-entity account mapping between USA 1 and USA 2, Intacct automatically adds:

Automatically generated line

Debit

Credit

Entity

Inter-entity receivable - due from USA 2

$350

—

USA 1

Inter-entity payable - due to USA 1

—

$350

USA 2

Important: Inter-entity entries are generated only when the expense line and Source Entity belong to different entities. Two different Locations that roll up to the same entity do not create an inter-entity transaction. The due-to and due-from accounts used depend on the Basic or Advanced inter-entity account mappings configured in Sage Intacct.

Can an expense be split across multiple entities?

✅ Yes, partially - by splitting the expense across Locations.

SEM’s expense-splitting workflow lets you divide one expense into multiple portions and assign a different Location to each portion. SEM then exports those portions as separate transaction lines with their selected Location values.

Because every Sage Intacct Location belongs to an entity, Intacct can determine which entity each portion is associated with from the Location/Entity hierarchy.

Example

A $300 hotel expense is split in SEM as follows:

Split portion

Amount

Location

Owning entity

Sales conference

$100

USA 1 – New York

USA 1

Customer meeting

$200

USA 2 – Los Angeles

USA 2

SEM exports two lines with their selected Locations, allowing Sage Intacct to identify the entity associated with each portion. The resulting behavior depends on the transaction type being exported and the Sage Intacct configuration.

Important: Location coding alone does not guarantee that each portion will post to the respective entity’s books or generate due-to/due-from entries. That behavior depends on the export type and Sage Intacct configuration. For automated inter-entity balancing, use the Top Level journal-entry workaround described above.

A Top Level connection is recommended for a cross-entity split because the integration must be able to access the Locations belonging to every affected entity.

Recommended workaround: If the split portions must post across multiple entities and automatically generate due-to/due-from entries, connect SEM at the Top Level and use the journal-entry setup described above (Can I create inter-entity transactions via exports from SEM to Sage Intacct?). This is a configuration workaround, not a native SEM “split by entity” feature.

Can required dimensions be configured independently per entity?

❌ Not within a single Top Level–connected SEM org.

SEM lets you mark dimensions (e.g., Department, Project) as required, but that setting applies globally across the org—it can’t vary by entity within a single Top Level–connected org. If one entity needs a Grant ID and another only needs Department and Project, SEM can’t enforce that difference within one org today.

Recommendation:

  • If every entity can use the same required fields, connect one SEM org at the Top Level and configure a universal set of requirements.

  • If entities need materially different fields or validation rules, connect each entity to a separate SEM org. Each org can then import and require only the dimensions relevant to that entity.

Can one SEM org manage taxes for multiple Sage Intacct entities?

❌ No. SEM supports Sage Intacct taxes only through an entity-level connection, not through a Top Level connection.

Each SEM org uses the base currency and Sage Intacct tax solution automatically determined by its connected entity. Therefore, every entity requiring taxes needs a separate SEM org.

For example, Australian and New Zealand entities can use taxes, but each must be connected to its own SEM org.

Additional limitations:

  • US taxes are not supported because tax-detail import is unavailable for USD-based SEM orgs.

  • SEM supports only one tax per expense. Dual-tax or multi-tax configurations, such as certain Canadian tax scenarios, are not supported.

  • As of now, tax sync is not supported when exporting expenses as ‘Expense Reports’.

Overview of recommended set up

Requirement

Recommended setup

Shared policies and dimensions; no taxes

One Top Level–connected SEM org

Entity-specific dimensions or policies

One SEM org per entity

Taxes required

One entity-level SEM org per entity

Automated due-to/due-from

Top Level JE workaround

FAQs

Can duplicate expenses be detected across separate SEM orgs?

❌ No. Duplicate detection is limited to one SEM org and does not compare expenses submitted in another org.

Can required dimensions vary by entity?

❌ Not within one Top Level–connected SEM org. Required-field settings apply to the entire org. Use separate SEM orgs when entities need different required dimensions or validation rules.

Can one SEM org manage taxes for multiple Sage Intacct entities?

❌ No. Taxes require an entity-level connection, so each entity requiring taxes needs its own SEM org. US taxes and dual- or multi-tax configurations, such as certain Canadian tax scenarios, are not supported.

Did this answer your question?