Multi-Entity AP Automation: What to Test Before You Buy

In multi-entity AP automation, look for shared vendors without duplicate records, approvals scoped by entity, intercompany entries, payment from each entity's own account, consolidated reporting, and virtual cards issued per entity. Then test each one live.

That last part is where most evaluations go soft. Every vendor in the category puts "multi-entity" on a slide, and almost every demo runs inside one tidy entity with clean sample data. The gaps show up later, during implementation, when the second subsidiary's invoices start arriving and someone notices the vendor record doesn't know which company owes the money. The six tests below are meant to be run in the demo, on your own scenarios, before anyone signs.

Key Takeaways

• Multi-entity accounts payable automation should keep one vendor record across entities, with terms, remit-to details, and bank accounts held per entity.

• Approval rules need to follow the entity as well as the dollar amount, so an approver for one subsidiary can't release another subsidiary's payments.

• The payment has to leave from the paying entity's own bank account, and any charge paid on another entity's behalf should create a due-from receivable in the paying entity and a matching due-to payable in the entity that owes it.

• Consolidated reporting is only trustworthy when it's built from the same data as entity reporting, on a shared chart of accounts.

• Virtual cards support multi-entity organizations when each card is issued under a specific entity and reconciles to that entity's general ledger.

What should you look for in AP automation software for multi-entity accounting?

Look for entity-aware records at every step, from vendor setup through payment and reporting. A platform passes when the entity travels with the invoice automatically, and fails when a person has to remember which company is paying.

In practice that comes down to six capabilities:

1. A shared vendor master with entity-specific terms and bank details

2. Approval routing scoped by entity, amount, and department

3. Payment funded from the correct entity's bank account

4. Intercompany entries booked on both sides when one entity pays for another

5. Consolidated and entity-level reporting from one dataset

6. Virtual cards issued and reconciled per entity

If you need the background on how these pieces fit together, the multi-entity AP explainer covers centralization and ERP fit. The tests below assume you're past that and already sitting in front of vendors.

My view is that items 2 and 3 matter most. Weak reporting is annoying and fixable with exports. A payment that leaves from the wrong bank account, or an approver who can release money for a company they don't oversee, is an audit finding and sometimes a real loss.

Why do generic demos hide multi-entity gaps?

Generic demos hide multi-entity gaps because they run one entity, one approver, and clean data. Nothing in that setup forces the software to decide which company owns an invoice.

Ask the presenter, partway through, to switch to a second entity without logging out and to show what changed. Watch whether the vendor list, the approval queue, and the bank accounts all change with it, or whether only a filter on the screen does. A polished demo can come apart on that one request, when the "entity switch" turns out to be a saved report view sitting on a single shared ledger. That's worth knowing in week one, before procurement.

How do you test multi-entity AP in a vendor demo?

Send the vendor a short script before the demo with your real entity names, a shared vendor, and two or three invoices, then ask them to run it live. A vendor that can't run your script in a sandbox before contract will struggle to run it in production.

Each test below includes what to ask for, what a pass looks like, and the answer that should worry you.

Test 1: Can one vendor be shared across entities without duplicate records?

A strong platform keeps one vendor record and attaches entity-specific details to it. Your office supply vendor might sell to four of your companies on different terms, remit to different addresses, and get paid from different bank accounts, and the system should hold all of that under one name.

Ask the vendor to add a new entity to an existing vendor and change the payment terms for that entity only. A pass shows the change on one entity while the others stay untouched. A fail sounds like "you'd create a second vendor record for that entity," which is how duplicate records start. Duplicate records are also how duplicate payments start, so ask how the platform's duplicate payment detection works across entities, and whether it catches the same invoice number submitted to two companies.

Bank-detail changes deserve their own question. According to the AFP's 2026 Payments Fraud and Control Survey, 76% of U.S. organizations experienced attempted or actual payments fraud in 2025, and 74% were affected by business email compromise. A shared vendor record means a single fraudulent bank change can redirect payments from every entity at once. Ask who approves a bank change, whether it applies to one entity or all of them, and how the platform handles vendor bank verification before the first payment goes out.

Test 2: Do approval rules follow the entity, not just the amount?

Approval rules should follow the entity first, then the amount and department. An approver who owns spend for one subsidiary shouldn't see or release another subsidiary's invoices unless you've granted that on purpose.

Give the vendor a small matrix with two entities, two departments, and two dollar thresholds, and ask them to build it during the call. Then submit an invoice for Entity B and log in as Entity A's controller. A pass is an empty queue. A fail is an invoice that shows up anyway because the rule only looked at the amount.

This is the multi-entity version of segregation of duties in AP, and it's easy to get wrong in setup even on a capable platform. Ask how many approval rules a typical customer with your entity count maintains, and who changes them when an approver leaves. If the answer involves a support ticket, budget for that.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

Test 3: Does the payment leave from the right entity's bank account?

The payment should come out of the bank account that belongs to the entity that owes the invoice. That sounds obvious, but it's the test most platforms handle with a workaround.

Ask the vendor to put invoices for one shared vendor from two different entities into a single payment run. A pass produces two payments, each funded from its own entity's account and each posted to its own ledger. Weaker platforms produce one combined payment from the parent's account with a note to sort it out later, which quietly creates an intercompany balance nobody approved.

Payment method mix matters here too, because each entity may pay differently. ACH carried $104.06 trillion in 2024, 74% of U.S. noncash payment value, while checks fell to 9.2 billion payments, about 4% of noncash payments by number, according to the Federal Reserve's 2025 Payments Study. Checks haven't gone away, though. The same AFP survey found that 72% of organizations that use checks plan to keep using them, and 68% of those cite vendor requirements. Corpay pays suppliers by virtual card, ACH, or check from one approval flow, which is the shape to look for when some entities still mail checks and others don't.

Test 4: How does the system book intercompany charges?

When one entity pays an invoice on behalf of another, the system should book a due-from entry (an intercompany receivable) in the paying entity and a matching due-to entry (an intercompany payable) in the entity that owes the expense. Both entries should come from the same transaction, without a manual journal.

Give the vendor a real example, such as a parent company paying a software subscription that three subsidiaries share. Ask them to split it by entity and show the resulting entries in each ledger. A pass shows the receivable and the payable balancing on both sides of the AP ledger, tagged so they can be eliminated at consolidation. A fail is "your ERP handles that," which may be true, but then the AP platform is passing you an unbalanced entry and your team is doing the matching by hand each month.

Ask, too, how the platform reports open intercompany balances at month end. The AP reconciliation work for a multi-entity group lives or dies on whether those balances tie out before close.

How should consolidated reporting work across entities?

Consolidated reporting should come from the same transactions that feed each entity's reports, so the totals always add up without a spreadsheet in between. If the consolidated view is a separate export, it will drift.

Test 5 is simple to run. Ask for AP aging by entity, then for the consolidated aging, and then check that the entity totals sum to the consolidated number on screen. Then ask for spend by vendor across all entities, which is where shared vendors start paying off in negotiating power.

The chart of accounts is the quiet dependency. APQC data reported by CFO.com in "Metric of the Month: Cycle Time for Monthly Close" puts the median monthly close at 6.4 calendar days, with top performers at 4.8 days or less and the bottom quarter at 10 or more. The same research found that organizations with widespread adoption of a standard chart of accounts shave about two days off their consolidated statements. That's 2018 data, but the mechanism hasn't changed. If your entities code to different charts, ask the vendor how invoice coding maps each entity's accounts to the consolidated view, and who maintains that mapping.

How do virtual cards support multi-entity organizations?

Virtual cards support multi-entity organizations by issuing each card under a specific entity, funding it from that entity's account, and reconciling every transaction to that entity's ledger. The card carries the entity with it, so nobody has to recode charges after the fact.

Test 6 checks that. Ask the vendor to issue a card payment for an invoice owed by your second entity, then show where the transaction lands in the books and whose credit line it used. A pass shows the right entity on the card, the right GL coding on the transaction, and a clean match back to the invoice. A fail is a single corporate card program where every charge lands in the parent and gets allocated manually.

Single-use cards fit multi-entity AP well because each card is created for one invoice, one amount, and one vendor. Corpay issues single-use virtual cards for supplier payments, so a card number exposed at one vendor can't be reused to charge another entity's account. If you're comparing how cards post back to your books, the details of virtual card ERP integration are worth a separate session with the vendor's integration team.

Rebates are the other question. Ask whether card rebates are reported by entity, or only as one number for the whole program. Subsidiary CFOs tend to care, and a per-entity rebate report avoids an argument at budget time.

Which questions separate real multi-entity support from a checkbox?

The fastest separator is asking how a new entity gets added. A platform built for multi-entity work treats a new subsidiary as configuration, done in days by your own team. A platform that treats it as a new implementation, a new contract, or a new instance will make every acquisition a project.

Several more questions are worth asking on every call:

• How many entities does your largest customer run in one instance, and how many in yours would be similar?

• Can a user scoped to one entity see another entity's vendors through search or export?

• What happens to open invoices and approvals when an entity is sold or closed?

• Which ERPs do you support for multi-entity structures, and do you write back to each entity separately?

That last answer varies more than vendors admit. NetSuite subsidiaries, Sage Intacct entities, and Business Central companies each model entities differently, and the NetSuite multi-subsidiary AP guide shows how much detail hides inside one ERP alone. Ask every vendor to show the write-back behavior in your ERP specifically, with your entity structure, before you take their integration list at face value.

One question I can't answer for you is where the line sits between one instance and two. Some groups with dozens of entities run happily in one, and some with five split them because two subsidiaries have nothing in common. Ask the vendor what their customers at your size actually do, and why.

Run AP across every entity with Corpay

Most multi-entity AP pain comes from the same place, which is a person deciding which company owes an invoice and which account pays it. Corpay's fully managed AP takes that decision out of the inbox.

With Corpay AP automation, invoices are coded and routed by entity, and you approve each payment file once. Corpay then pays each vendor by virtual card, ACH, or check, handles supplier enrollment, and earns card rebates that add up to more than $800M paid to Corpay customers each year. Customers save about 40% of the time spent on invoice processing, connect through 100+ ERP integrations including NetSuite, Sage Intacct, Business Central, and Acumatica, and are typically live in weeks.

Frequently Asked Questions

What is multi-entity AP automation?

Multi-entity AP automation is software that processes invoices and payments for several legal entities from one platform. It keeps vendors, approvals, bank accounts, and ledger postings tied to the right entity, and gives finance both entity-level and consolidated views of payables.

What's the best AP automation software for multi-entity accounting?

The best software for multi-entity accounting is the one that passes live tests on your own entities. Ask each vendor to share a vendor across entities, scope approvals by entity, pay from each entity's account, book intercompany entries, and issue cards per entity.

How do you pay a shared vendor from different entities?

Keep one vendor record with entity-specific terms and bank details, then let each entity's invoices pay from that entity's own bank account. A single run can include several entities, but each payment should be funded and posted separately.

Can AP automation handle intercompany payments?

Yes, if the platform books a due-from receivable in the paying entity and a due-to payable in the entity that owes the expense when one entity pays for another. Check that both entries come from the same transaction and are tagged for elimination, so intercompany balances tie out at month end without manual journals.

How long does it take to add a new entity?

On a platform built for multi-entity AP, adding an entity is configuration that takes days, covering its bank accounts, approvers, and vendor terms. If a vendor quotes a new implementation or a new contract per entity, expect each acquisition to become a project.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation

Payments Automation