Ramp ties every card — and every transaction — to one entity
If your business runs multiple legal entities on Ramp, you've probably run into this: an employee makes a purchase that should land on Subsidiary B's books, but their card is tied to Subsidiary A — and there's no obvious way for them to fix it.
That's not a bug. It's how Ramp's multi-entity model is designed to work. According to Ramp's own help documentation, each issued card is linked to a specific entity, with all transactions on the card attributed to that entity. The card's entity is set at the time of issuance — defaulting to whatever entity the cardholder's assigned location maps to — and from that point forward, every charge on the card is booked to that entity automatically.
Cardholders can't recode their own transactions — by design
This is the part that catches finance teams off guard: an employee who realizes their purchase was coded to the wrong entity generally cannot change it themselves. Ramp's help center addresses this directly in its multi-entity FAQ:
In other words, the ability for a cardholder to recode their own spend across entities isn't a setting you'll find anywhere in the Ramp admin console. It's an account-level capability that Ramp toggles on request — which means the only way to get it is to ask Ramp directly.
Why Ramp locks it down this way
The restriction isn't arbitrary. Ramp calculates statement payments at the entity level, paying each one out of the bank account configured in that entity's settings. If cardholders could freely reassign transactions after the fact, the amount charged to an entity's cards could stop matching the amount paid out of that entity's account — which is exactly the kind of mismatch that turns a clean monthly close into a reconciliation project.
Locking the entity to the card — and the transaction to the entity — keeps the books predictable: what was charged on Entity A's cards is what gets paid from Entity A's account, every time.
What admins can do — and the deadline that matters
Admins (as opposed to cardholders) do have a path to fix a miscoded transaction, but it's time-boxed:
- Open the transaction and locate the entity field in the transaction drawer.
- Click the drop-down and select the correct entity.
- Do this before the monthly statement generates — once the statement closes, the entity on every transaction inside it is permanently locked and can no longer be changed.
Ramp's actual recommendation: stop recoding, start separating
Rather than treating cross-entity recoding as the fix, Ramp's guidance points teams toward avoiding the problem at the source. If an employee regularly needs to spend on behalf of more than one entity, Ramp's documented suggestion is to issue a separate virtual card or fund for each entity — one for Entity A, another for Entity B — rather than routing all of that person's spend through a single card and sorting it out later.
This keeps each card's transactions, and each entity's statement payment, aligned from the moment the charge is made. It also sidesteps a structural limitation Ramp is explicit about: it only supports one physical card per employee, and the business name and logo on that card must be identical across every entity it could be associated with — another reason multiple virtual cards, not one shared card, is the supported pattern for cross-entity spenders.
Splitting one transaction across entities: platform-dependent
It's worth separating "recoding a transaction to a different entity" from "splitting a single transaction across multiple entities" — Ramp treats these differently, and the answer depends on your accounting platform:
- NetSuite: Not supported. Ramp's FAQ states plainly that NetSuite itself does not allow a transaction to be split across entities, so Ramp can't offer it for NetSuite-connected accounts either.
- Sage Intacct: Possible, but constrained — you can split across locations (which may map to entities), limited to the locations available within the location group where the card was originally created.
How to actually request the change
If your team genuinely needs cardholders to be able to recode their own transactions across entities — rather than relying on admins to catch and fix miscodes before each statement closes — the path is straightforward:
Be specific in the request: name the capability ("allow employees to change the entity field on their own transactions"), and be ready to explain why — for example, that your team structure routinely has individuals purchasing on behalf of entities other than the one their assigned location maps to. Ramp frames this explicitly as something it will enable on request, not something that ships on by default, so the clearer the use case, the faster support can action it.
Getting your multi-entity setup right from the start
Most of the friction described here disappears when entities, locations, and card issuance are mapped correctly during setup — before the first miscoded transaction ever happens. That's the kind of structural work that determines whether your monthly close is a formality or a fire drill.
SuiteCrunch designs Ramp implementations around exactly this — procurement operations, entity mapping, and approval governance built to match how your business actually runs, not just how the platform defaults to working. If multi-entity coding is already causing reconciliation headaches, it's worth a conversation about how we approach Ramp implementation design →.