Handling Multi-Entity Card Spend in Sage Intacct

Card spend is easy in a single-entity Intacct company. You have one set of books, one card account, and the only real question is which dimensions each charge gets. It gets harder once you add a second LLC, a property-holding company, or a new operating subsidiary. Each charge now also needs an owner, and the card program usually wasn't set up with that in mind.

This post covers how Intacct expects multi-entity card spend to work, what to do with charges that land on the wrong entity's card, and how to set up an expense tool so it doesn't create a cleanup job at month end.

Start with how Intacct thinks about entities

Sage Intacct's multi-entity overview defines an entity as "a separate tax identification or a separately secured, fully balancing set of books." The top level is where you manage shared resources such as the chart of accounts, vendors and users. From the top level you can enter transactions and pick the entity they post to. At the entity level, each business unit transacts and reports on its own and can't see the other entities' data.

Card accounts follow the same model as cash accounts: a card is owned by one entity. As CLA describes Intacct's credit card setup, the card's default entity "is the entity that owns the card, similar to how cash accounts belong to a single entity," and each card links to one vendor (the issuer) for the charge payoff. The liability belongs to the owning entity, so its charges post there too.

Everything else follows from that rule. Multi-entity card spend works best when the card program lines up with the entity structure.

Step 1: Map every card to exactly one entity

List every corporate card and write down which entity is legally responsible for paying it. Usually that's whoever the issuer bills. Then check that each card's account in Intacct is owned by that entity.

Most of the pain comes from two patterns:

• One card shared across entities. For example, an operations manager's card that pays for supplies at three properties held in three LLCs. The card's liability sits in one entity while the spend belongs to all three.
• Cards set up before an entity existed. The new subsidiary launched in March, but its people are still using cards the parent entity owns.

Neither can be fixed in the expense tool alone. Where you can, move to cards per entity: most issuers will open separate accounts or billing units under one relationship. The cleanest multi-entity setup is the one where a charge's entity follows from the card that was used.

Step 2: Decide what gets shared across entities

Entities in one Intacct company usually share a chart of accounts. Other dimensions vary. Departments might be common to all entities, while projects, properties or locations belong to just one.

Decide deliberately, per dimension type:

• Shared: every entity codes against the same values. This works for the GL accounts and departments in most companies.
• Shared with local additions: the common list plus a few entity-specific values.
• Independent: each entity keeps its own list. This usually applies to projects, jobs and properties.

This matters for card coding. A coding rule or AI suggestion should only offer values that are valid for the entity the charge is posting to. If someone at Entity A can pick a project that belongs to Entity B, you'll get a posting error or a charge sitting in the wrong books.

Step 3: Handle the cross-entity charge on purpose

Some charges will still be paid by one entity on behalf of another, even with good card hygiene. That's an intercompany transaction, and Intacct has machinery for it. According to Intacct's inter-entity transaction FAQ, automatic inter-entity entries apply to journals, adjusting journals and recurring journals. Inter-entity account mappings (the due-to/due-from receivable and payable accounts) have to be set up before those entries post.

A practical method many controllers use:

1. Post the charge where the card lives. It posts as a charge card transaction in the paying entity, so the card register and the statement reconcile cleanly.
2. Code it to a holding account or flag it. A dedicated "paid on behalf of" GL account, or a consistent memo convention, makes these charges easy to find.
3. Reclass monthly with one journal entry. Move the month's cross-entity total to the right entities. Intacct's inter-entity mappings create the due-to/due-from lines automatically.

The alternative is re-entering each misplaced charge by hand in the correct entity. That breaks the link between the card statement and the card register, and your reconciliation turns into detective work.

Step 4: Treat defaults as a control, not just a convenience

In a multi-entity company, a default location or department on a card connection does more than save clicks. When most of a card's spend belongs to one site, setting that default stops the most common coding error: the right GL account in the wrong location, which then consolidates correctly but reports wrong at the entity level.

Check exceptions against those defaults. A charge that overrides its card's default location is the one most worth a reviewer's second look.

How Summit Spend handles it

In Summit Spend, each Intacct entity is its own entity in Summit Spend. You get a parent organization and a child organization per entity, all connected to the same Intacct company. Each child posts in its own entity context. Charge card transactions land in that entity with dimensions validated against that entity's values, and dimension sync runs per entity. For each dimension type you choose whether children use the parent's values, the parent's values plus local additions, or their own lists. Default GL and dimension values can be set on each card connection.

Two things we deliberately don't do. We don't split one card's charges across entities, because a card belongs to one entity, matching Intacct. And we don't generate intercompany entries. The monthly reclass in Step 3 stays in Intacct, where the inter-entity mappings live.

Multi-entity is included in Professional for up to five entities (a parent plus four children), and Enterprise has no entity limit. If your card program and entity structure don't line up yet, request access. We're happy to walk through the mapping with you before anything is connected.