Why Intercompany Reconciliation Starts in Accounts Payable

Intercompany reconciliation starts in accounts payable, when one company pays a bill another company owes. Pay each bill from the company that owes it, and there is far less to reconcile at month-end.

The fix is to keep each entity's books, bank account and approvers separate, and put only the day-to-day work in one place. MakersHub is set up around how your business already works, and our team configures it with you.

Charley Howe, our co-founder and President, has been watching this pattern grow as larger, multi-entity operators move onto MakersHub. Here is how he put it on LinkedIn:

The post names the shortcut. The rest of this article covers what it does to the books, why it persists, what the alternative looks like day to day, and when paying from one entity is still the right call.

Why is accounts payable harder with more than one entity?

The number of bills is not usually what makes this hard. A business with five entities and 400 bills a month does not have five times the work of a single company with 400 bills. It has the same 400 bills, plus a decision on every one of them: which company owes this?

That decision carries three others behind it. The bill has to land in the right entity's books, which usually means a separate company file or subsidiary in the accounting system. It has to be coded to that entity's chart of accounts, the list of expense and balance accounts each company keeps, and those lists often differ from one entity to the next. And it has to be paid from that entity's bank account, by people with authority to move that entity's money.

None of this is unusual or limited to large groups. The examples in Charley's post run from homebuilders with a separate QuickBooks file for every project to a real estate group with 55 entities. In a Journal of Accountancy piece on intercompany accounting, Kyle Cheney, a certified public accountant (CPA) and partner in Deloitte's advisory practice, made the same point about company size:

The same article reported a 2016 Deloitte poll of more than 3,800 accounting and finance professionals. The most commonly named intercompany problem was disparate software systems across legal entities, cited by 21.4% of respondents, followed by intercompany settlement at 16.8%. Only 9.2% said an intercompany accounting framework was in place. The poll is a decade old, so read the exact percentages as a rough guide. The two top answers still describe exactly what an AP team sees every day: different systems per entity, and money that has to be squared up between them.

What happens when the holding company pays everything?

The holding-company shortcut is common because it works on day one. Every bill goes to one inbox, someone approves it, and the holding company pays it from one account. There is one login, one bank relationship and one payment run. The cost shows up later, in the books.

Here is what one paid bill turns into. Say the holding company pays a roofing contractor for work on a building owned by one of its property LLCs, the limited liability companies that each hold one asset. To keep both sets of books honest, someone records three things:

That is the journal entry cleanup in Charley's post, and it repeats for every bill paid this way. Intuit's guide to multi-entity finance describes the same mechanics: each intercompany transaction has to be recorded on both sides, matched and eliminated before the consolidated numbers can be trusted. Multiply that by every bill, every month, across every entity, and intercompany reconciliation (proving that both sides agree) becomes a standing part of the close.

Three things tend to go wrong along the way:

None of these are failures of effort. They come from asking people to rebuild, by hand, a separation that the payment already erased.

Why do the books need to stay separate at all?

Entities usually exist for a reason. A lender underwrites one company's financial statements. An investor owns a stake in one property and not the others. A project is set up as its own company to contain its liability. A family office holds each asset in its own LLC. In every case, someone outside the business is relying on that entity's books standing on their own.

When another company pays an entity's bills, those books stop standing on their own until the intercompany entries catch up. The expenses are real but the cash came from elsewhere, and the balance sheet carries a payable to an affiliate that a lender or buyer will ask about.

There is a legal side too, and it belongs with your attorney rather than your AP software. Cornell Law School's Legal Information Institute lists intermingling of personal and corporate assets among the kinds of misconduct that can justify piercing the corporate veil. That is the step where a court holds an owner responsible for a company's debts. The LII also notes a strong presumption against doing so. How that applies between affiliated companies depends on the facts. The practical point is simpler: clean, separate payment records are easier to defend than ones rebuilt with journal entries.

Deloitte's Center for Controllership sees a related pattern in larger organizations. Based on its work advising clients, it keeps seeing the same challenges in intercompany reconciliation and settlement: processes managed separately by different teams, inefficient communication between them, and a lack of central oversight. Paying from the holding company looks like central oversight, but it only centralizes the payment. The accounting is still split across entities, just later and by hand.

What does keeping the books separate and unifying the work look like?

It means drawing the line in a different place. The things that legally and financially belong to each entity stay with that entity. The work itself (reading, routing and reviewing bills) moves into one place.

In MakersHub, that looks like this. A bill arrives in the shared inbox. WiseVision, the AI that reads bills in MakersHub, reads the whole document, line items included, not just the header. That means the project name, lot number, service address or job on the page can decide which entity and which accounts the bill belongs to. You set your coding rules once, and MakersHub applies them everywhere. When a vendor bills several of your entities, each bill still lands in the right company. You can configure MakersHub by talking to it. Prompt WiseVision to code a bill, then ask it to save that decision as a rule it applies from then on. Because line-level automated coding codes each line to the right entity's chart of accounts, nobody has to retype lines.

Approval then follows the entity's own chain. Approvers use MakersHub without training. They approve from email in one click, and see only the bills that are theirs, so a site manager at one property never sees another company's payables. Payment is a separate step from approval. People with authority for that entity release it from that entity's own bank account, by ACH (the US bank-to-bank transfer network), check or wire. Our payment workflow for ACH, check and wire keeps those roles split by design, with check numbers and ACH trace numbers logged with each payment.

Security reviewers tend to ask about this setup first, since every entity's bank account is now reachable from one place. SOC 2 Type II is an outside auditor's report on whether a company's security controls actually worked over several months, and Positive Pay is a bank service that checks each presented check against the list you issued. MakersHub is SOC 2 Type II certified, with Positive Pay protection on check payments and encrypted collection of vendor bank details.

Finally, the bill and its payment sync to the entity's own ledger through a two-way integration, so the expense and the cash land in the same company. There is no due-to or due-from balance to create, because no other company paid it.

This works even when entities run different accounting systems, which is common in groups built through acquisition. MakersHub builds and maintains every integration itself, with no middleware in between. They cover QuickBooks Online, QuickBooks Desktop through the Web Connector (Intuit's sync tool for Desktop), NetSuite, Sage Intacct, Xero and Intuit Enterprise Suite. Smart Data Connect covers any other ERP, the enterprise resource planning system some larger companies keep their books in. See the full list on our accounting system integration hub.

Provignage, which runs AP for a portfolio of wineries, is a good example of the separation working in practice. Its controller manages five or more entities in MakersHub, reached 90%+ invoice data accuracy and pays vendors three times faster with next-day processing, without adding staff. You can read the details in the Provignage multi-entity customer story.

How do the three common setups compare?

Most groups land in one of three places. The difference is where the effort goes, and whether it lands before the payment or after it.

The third setup is the honest alternative to the shortcut, and plenty of groups run it. It keeps the books clean, at the cost of a team doing the same work several times over in several places. The first setup keeps the clean books and removes the repetition.

When does paying from one entity still make sense?

Some bills genuinely belong to more than one company. A single insurance policy covering every entity, a shared office lease or one software subscription used across the group will often be billed to one company and shared with the rest. Those create real intercompany balances no matter how AP is set up. The goal is not zero intercompany entries. It is intercompany entries that are deliberate, documented and few, rather than one for every bill.

For shared bills, splitting at the line level helps. When MakersHub reads every line of a bill, each entity's portion can be coded to the right company and recorded as a known allocation, instead of being discovered at month-end.

Larger groups sometimes centralize payments on purpose through a shared services company, with written intercompany agreements, a set settlement schedule and a treasury team that nets the balances. That is a designed process with an owner, which is very different from paying everything from the holding company because it was easier. If you run it that way, the same rule applies: every bill still needs to reach the right entity's books, coded to that entity's accounts, on the day it is paid.

How do you move from one bank account to entity-by-entity payments?

Teams that make this change usually do it entity by entity rather than all at once. A workable order:

MakersHub is transparent about where every bill sits and who is holding it, which matters more during a transition than at any other time. And because there is no limit on transactions, users or entities, and no per-user pricing, a new entity is a setup task rather than a pricing conversation. Our guide to configurable AP software covers how routing rules adapt to your process rather than the other way around.

If you are comparing platforms for this, our comparison of AP automation software for multi-entity businesses walks through how eight vendors handle entities. Our real estate AP automation page shows the property-by-property version of this setup.

Frequently asked questions

What is intercompany reconciliation?

Intercompany reconciliation is the process of confirming that transactions between companies in the same group are recorded the same way on both sides, so the balances can be eliminated when the group consolidates its financials. Much of that work starts in accounts payable, whenever one entity pays a bill that belongs to another. MakersHub reduces it at the source by paying each entity's bills from that entity's own bank account, so most of those intercompany entries are never created.

Why does paying bills from a holding company create intercompany entries?

Because the company that paid the bill is not the company that owes it. The holding company records a due-from balance, an intercompany receivable, and the entity records the expense plus a due-to balance, an intercompany payable, for every bill paid this way. MakersHub avoids that by keeping one shared inbox for the AP team while paying and syncing each bill entity by entity.

Can one AP team handle bills for many entities without merging their books?

Yes. The books, bank accounts and approval roles stay with each entity, while the inbox, the review screen and the payment run are shared. MakersHub is set up around how your business already works, and our team configures it with you, so each bill is coded to the right entity's chart of accounts and synced into that entity's own ledger.

What if our entities use different accounting systems?

That is common, especially in groups that grew through acquisition, and it does not have to be fixed before you automate AP. MakersHub syncs two ways with QuickBooks Online, QuickBooks Desktop, NetSuite, Sage Intacct, Xero and Intuit Enterprise Suite, plus Smart Data Connect for any other ERP, and every integration is built and maintained in-house rather than through middleware.

How does a bill get routed to the right entity if the vendor leaves off the project or lot number?

The entity has to be read from whatever else is on the bill, such as the service address, ship-to location, job name, PO number or the vendor's history. MakersHub reads every line of the bill, not only the totals at the top. You set your coding rules once, and MakersHub applies them everywhere. Where nothing on the bill identifies the entity, someone on your team assigns it once, and that choice can become a rule.

Is there a limit on how many entities we can run?

Some AP platforms price by entity or put multi-entity features on a higher tier, so it is worth checking at the entity count you expect to reach, not the one you have today. MakersHub has no limit on transactions, users or entities and no per-user pricing, and customers run anywhere from a handful of entities to more than fifty.

Does keeping entities separate in AP strengthen or weaken controls?

It strengthens them, because each entity's money can only move with approval from that entity's own people. MakersHub keeps bill approval separate from payment authorization by design, and each entity runs its own approval and authorization roles. MakersHub is SOC 2 Type II certified, with Positive Pay protection on check payments and encrypted collection of vendor bank details.

Multi-entity AP is not a volume problem. It is a structure problem. We built MakersHub so a group with five entities, or fifty-five, can keep its books separate and still run AP as one team. If your close still includes journal entries for bills one company paid for another, we'd like to see it. Get started with MakersHub.

Sources: Journal of Accountancy (AICPA), “5 best practices for intercompany accounting,” December 2016, including a 2016 Deloitte poll; Deloitte Center for Controllership, “Efficient integration for intercompany accounting”; Intuit Enterprise Suite, “Multi-entity challenges for growing businesses,” April 2026; Cornell Law School Legal Information Institute, “piercing the corporate veil”; MakersHub published customer stories.