Multi-entity QuickBooks

Start with the fact everything else on this page follows from:

A QuickBooks bill belongs to one company. There is no cross-company posting anywhere in the QuickBooks Online API. Every write is scoped to a single company file, and no field on a bill names another company. Intuit does not publish an intercompany transaction for third parties to call.

So an invoice split across ownership entities that keep separate books cannot become one bill. It becomes one bill per company, each carrying that company's own share. InletAP calls that a fan-out, and it tells you about it before you press Export.

Two different situations, and they are not equally hard

The first case is most management companies and it is the simple one. The second is joint ventures, syndicated deals, and any structure where an owner's accountant requires their own books.

The unit of fan-out is the company, not the entity

This distinction is worth a paragraph because it is the difference between correct and wrong accounting.

Three partnerships that share one set of books are three ownership entities and one company. Their slices of one invoice belong on one bill, told apart by the class on each line. Posting three bills into one company would double and triple the payable for a single invoice.

The same three partnerships on three separate QuickBooks companies are three bills, because no bill can reach into another company's ledger.

So InletAP groups allocations by the QuickBooks company their entity points at. "How many bills?" is always answered by counting distinct companies, never by counting entities.

Mapping an entity to a company

Each ownership entity can name the QuickBooks company its bills post to. Connect each company as its own connector, then set the company on the entity.

The fallback is not an error. An entity may legitimately have no books of its own, and a workspace that has connected one company so far is the ordinary starting point. But it is reported: the export plan lists the entities that are falling back, because "posts as 1 bill" when you expected three is a surprise that has to happen before the Export button rather than after it.

Reference data — accounts, classes, vendors, tax codes — is mapped per company. The same property maps to a different class ID in each company, which is exactly right: the two companies are two ledgers that happen to share a building's name.

The fan-out banner

The moment a document's allocations reach more than one company, the review screen states what will happen above the Export button:

2 ownership companies -> posts as 2 QuickBooks bills:
Maple Ct LP 4233.34 · Elm/Oak JV 8246.66

That is the $12,480.00 GreenLeaf invoice from splitting an invoice: Maple Court belongs to Maple Ct LP, Elm Terrace and Oak Ridge both belong to Elm/Oak JV, and the two companies' shares total the invoice.

A document that does not fan out says Posts as 1 QuickBooks bill, which is every invoice in an unsplit workspace and most invoices in a split one.

The banner also carries warnings when the target company cannot do what the coding asks:

If your properties are QuickBooks Locations, line-level splitting cannot work

You need to know this from us, in the docs, rather than from a failed export.

On a QuickBooks bill, the class and the customer are per line. The location — DepartmentRef, whatever your company calls it — is a header field. One location for the whole bill, and it cannot vary by line.

So a workspace that models properties as Locations cannot split one bill across properties at all. There is nowhere on the bill for the second property to go. The options are real ones:

• Model properties as classes. The per-line field, and the one this feature is built on.
• Model properties as sub-customers. Also per line. A parent customer may hold sub-customers up to four levels deep, so entity → property → unit fits comfortably. Note that a customer which is a QuickBooks Project cannot contain sub-customers.
• Keep locations, and split at the entity level only — one bill per company, each with a single location, and no per-property coding within a company.

InletAP says so rather than dropping the coding silently. A bill that posts with two of three properties missing is worse than a bill that does not post.

The QuickBooks Plus ceiling: 40 classes and locations combined

QuickBooks Online Plus allows 40 classes and locations combined. Not 40 of each — 40 in total. Advanced removes the limit. (Plus also caps the chart of accounts at 250 accounts, which portfolios reach for a different reason.)

The consequence is blunt: a portfolio of 41 or more buildings cannot model property-as-class on Plus. That is a fact about the ledger, not about InletAP, and it is worth knowing while you are designing your books rather than at the moment a class create is rejected. Past 40, the routes are sub-customers or QuickBooks Advanced.

What a split invoice looks like in QuickBooks

Within one company, a split invoice posts as one bill with one line per allocation:

• The GL account comes from the allocation's own code.
• The class is the allocation's property.
• The description carries the property name alongside the vendor's own line text, so the bill is legible to whoever opens it in QuickBooks and not just to whoever coded it here.
• The location, where you use locations, is a header field taken from the bill's own target.

Each posted bill records the ID QuickBooks returns, so every slice of a fanned-out invoice is one click from the bill it became.

partially_exported

Fan-out introduces a state that a single-bill export never had: two bills posted, one parked.

That document's status is partially_exported. It means exactly what it says — part of this invoice is in your ledger and part is not — and it is deliberately not exported and not failed_export, because both of those would be a lie about the money.

The export screen shows one row per target, with its own status, its own amount, and a link into the bill where one exists. Retry works on the failed target alone: the companies that posted are not touched, and each bill carries its own request identity, so a retry of the parked target cannot re-post the two that succeeded. See export failures.

What InletAP does not do: intercompany posting

Plainly, so that nobody discovers it during a close:

InletAP does not create due-to / due-from entries, and it does not do intercompany eliminations. It posts each company's own share into that company's own books, and stops there.

If one entity pays the vendor on behalf of the others, the resulting receivable between your entities is a decision for your accountant, and the journal that records it belongs in your ledger, not in an AP tool. What InletAP gives you is the accurate, auditable split those journals are built from, and one posted bill per company that matches it to the cent.

Intuit's own answer for consolidated multi-entity accounting is a separate product from QuickBooks Online, and consolidation tools in this space generally read several companies for reporting rather than post between them.

Where to go next

• Splitting an invoice — where the allocations come from.
• Exports reference — what is written, and how retries avoid a double post.
• Export failures — including a partial failure across companies.
• Connecting QuickBooks — connecting each company.
• Invoice statuses — where partially_exported sits.