AP Automation for Separate Companies and Multiple ERP Systems

AP automation for multiple ERP systems means running one accounts payable process across separate companies that do not share a general ledger. Each entity keeps its own books, its own approvers, and its own coding rules, while invoices, communications, and payments move through a single workflow your team actually recognizes from one company to the next.

Most finance teams do not arrive at this setup by design. They arrive through acquisition, a new product line, a spun-up subsidiary, or a merger that brought a second ERP along with it. The work then splits: two logins, two coding conventions, two approval matrices, and a close that runs on whichever entity is slowest. This post covers why multi-entity AP breaks first, the three structures teams actually run, and what it takes to hold one process together across all of them.

Why multi-entity AP breaks before anything else

Complexity, not headcount, is what makes AP hard. A company with 60 people and four legal entities has a harder AP problem than a company with 600 people and one.

The close data reflects it. APQC’s research on the annual closing process finds that top-performing organizations finish in 10 days or less, against a median of 18 days and 35 days for slower performers. APQC also notes the spread by size: organizations under $100 million in revenue post a median annual close of 10 days, while those between $1 billion and $5 billion sit at 23 days. Entity count, intercompany volume, and reporting obligations drive most of that difference.

AP feels it first because AP is where the entity boundary is easiest to cross by accident. An invoice arrives at a shared inbox with no company indicator. A shared vendor bills two subsidiaries on one document. A coder who works across three entities selects a GL account that is valid in one of them. None of these are exotic. They are the ordinary Tuesday of a multi-entity AP team, and each one becomes a correcting entry later.

Exception volume compounds it. Ardent Partners’ Accounts Payable Metrics That Matter in 2025 reports that best-in-class AP organizations hold invoice exception rates at 9%, while the broader average runs at 22%. In a single-entity business, an exception costs an email. Across entities, it can cost a reopened period.

For a Controller, that is the version of this worth bringing to leadership: entity-level coding errors are not an AP productivity issue, they are an audit trail issue with a quantified cost in reopened periods and reconciliation hours.

Three multi-entity AP structures

Almost every multi-company setup falls into one of three patterns. Which one you run changes what the AP process has to handle, because the requirements diverge sharply.

One ERP, one instance, multiple entities

The cleanest case. Subsidiaries, divisions, or locations share a single ERP instance and are separated by entity, company code, or dimension. An AP platform should handle this in one workspace, using the ERP’s own entity structure to route invoices, filter coding options, and apply the right approval path.

The requirement here is filtering, not separation. A coder working across entities should only ever see valid combinations for the entity on the invoice in front of them.

One ERP, multiple instances

Common after acquisitions where the acquired business runs the same ERP but in its own tenant, often with a different chart of accounts and different custom fields. The systems look identical and behave differently. Coding conventions rarely match, and vendor masters almost never do.

This pattern needs the AP platform to maintain a distinct configuration per instance while keeping the working experience consistent for the people processing invoices.

Different ERP systems entirely

A manufacturer running one ERP at the parent and a different system at a recently acquired division. A dealership group with a DMS at the stores and a separate accounting platform at the holding company. A construction firm with a job-costing ERP alongside a general system for corporate overhead.

Here the ERPs post differently, validate differently, and expose different field structures. The AP platform cannot flatten those differences and should not try. What it can do is give both teams the same intake, the same approval interface, the same communication history, and the same audit trail, while writing back into each ERP on that system’s terms. That is the real payoff of AP automation for multiple ERP systems: one process, two systems of record, no shared spreadsheet in the middle.

What entity routing actually requires

Routing is the mechanic that makes any of this work. Four pieces have to be in place.

• Entity identification at intake. Dedicated intake addresses per entity, so an invoice is attributed before anyone touches it. Relying on a coder to identify the entity from the letterhead is where errors begin.
• Entity codes tied to people. Every entity, location, or division needs its own set of coders and approvers, and a user’s assignments determine what they can see and act on.
• Approval paths per entity. The same expense type may need a different approver in each company. Approval logic should be configurable per entity without duplicating the whole workflow.
• Visibility limits. Users see what they need and nothing else. This is a control, not a convenience, and it is one of the first things an auditor will test in a shared-services environment.

Done properly, this also strengthens the internal controls you already have rather than adding a parallel set. Segregation of duties, approval thresholds, and three-way matching all still live in your control framework. Entity-aware routing enforces them earlier.

Keeping coding and dimensions intact

Coding drift is the quiet failure mode in multi-entity AP. It rarely announces itself. It surfaces at close, in a variance nobody can explain, and it lands on the controls and audit side of the house rather than on AP.

Three practices hold it back. First, filter coding options dynamically so only valid combinations for that entity and vendor are selectable. Second, apply defaults at the vendor and entity level so recurring spend codes the same way every month. Allocation templates do a lot of work here for shared costs that split across entities. Third, validate before posting rather than reconciling after, so an invalid combination never reaches the ledger in the first place.

Vendor records deserve the same discipline. A shared supplier billing three entities should exist once in your process with entity-level payment terms and remittance detail, not three times with three slightly different spellings. Our guide to the accounts payable vendor management process covers how to keep that master clean as entity count grows.

Distributed and shared services AP teams

Multi-entity structures rarely come with co-located teams. Processing may sit centrally in a shared services group, locally at each entity, or in some split where capture is central and approval is local.

All three work. What matters is that assignment logic follows the org design rather than the other way around. A shared services coder handling four entities needs the coding options to change automatically as they move between invoices. A local approver at one subsidiary should never see another entity’s payables. And when volume shifts between entities, reassigning work should be a settings change, not a reimplementation.

This is also where multi-location operators see the largest gains. Groups running many sites on shared systems, from healthcare networks to auto dealership groups scaling across locations, tend to find that standardizing intake and approval across sites is the change that actually compresses cycle time.

What standardizing across entities requires

Standardizing does not mean forcing every company onto identical rules. Each entity keeps its own chart of accounts, approval thresholds, and posting behavior. What gets standardized is the process wrapped around them. Seven things have to hold:

1. One working environment across entities. Coders and approvers move between companies without switching tools or relearning a second interface.
2. Coding that filters by entity and vendor. Only combinations valid for the entity on the invoice are selectable, custom fields included.
3. Approval paths that differ per entity. The same expense type can route to a different approver in each company without duplicating the whole workflow.
4. Independent posting behavior per ERP. Each system receives transactions on its own terms, with its own coding structure and validation rules intact.
5. Vendor records that carry entity-level detail. A shared supplier holds different payment terms and remittance detail per company from a single record.
6. An audit trail that survives the boundary. Every reroute, reassignment, and edit is captured, including work that moves between entities or approvers.
7. New entities as configuration, not implementation. Adding a company is a settings change rather than a second deployment.

The fourth item is the one that separates genuine multi-ERP support from a single integration with a second connection bolted on. Our guide to choosing the best AP integration for your ERP covers the ten technical factors underneath it, including sync timing, field-level coverage, and validation timing.

How Stampli handles separate companies and multiple ERPs

Stampli was built for operational complexity rather than company size. The ERP stays the system of record in every case, and Stampli mirrors each system’s GL structure, dimensions, entities, vendors, and approval hierarchies so work is validated and coded correctly before it posts back.

For separate companies on the same ERP, that means one platform, entity-aware routing, and coding options that filter to what is valid for the entity on the invoice. For businesses running two or more different ERPs, it means each system keeps its own configuration and posting rules while your team works in one consistent interface, with the same intake, approval, communication history, and audit trail across both.

Stampli AI performs on average 87% of finance work across 2,700+ unique fields, with every suggested entry subject to human review and approval before it reaches the ERP. Today that runs across 1,800+ customers operating inside their ERP ecosystem, covering 2,800+ entities and 400k+ invoices processed per week. Teams add entities, approval paths, and vendors as the business changes without rebuilding the workflow. You can see the full picture on our AP automation platform page or review supported accounting systems and ERPs.

Frequently asked questions

Can one AP automation platform support multiple ERP systems? Yes. A platform can maintain a separate configuration for each ERP, including its own chart of accounts, dimensions, custom fields, and posting rules, while giving finance teams a single consistent workflow for capture, coding, approval, and communication. The ERPs remain independent systems of record and each receives transactions on its own terms.

How does AP automation keep separate companies’ invoices apart? Entity codes, dedicated intake addresses per company, and user-level assignments. An invoice is attributed to an entity at intake, coding options filter to what is valid for that entity, and only the coders and approvers assigned to it can view or act on it. That separation is enforced by the platform rather than by team discipline.

Do multi-entity businesses need one Stampli account or several? It depends on the structure. Separate companies sharing a single ERP instance are typically managed together with entity-aware routing. Businesses running genuinely different ERP systems, or separate instances with different coding structures, are configured per system so each posts correctly to its own environment.

Does multi-entity AP automation help with month-end close? It helps by reducing what has to be corrected. Validating coding against each entity’s ERP rules before posting means fewer correcting entries and fewer unexplained variances during consolidation. Our guide to the accounts payable month-end close process covers where AP typically holds up the close.

Scale complexity without scaling headcount

Growth adds entities faster than it adds finance staff. The teams that handle it well are usually the ones who stopped treating each new company as a new process and standardized the parts that should be identical: intake, approval, communication, and audit trail, while letting each ERP stay exactly as different as it needs to be.

If you are running separate companies, multiple ERPs, or both, talk to our team about how your structure would map into a single AP workflow.