--- title: Posting to several companies description: A bill belongs to one set of books, so an invoice split across ownership entities with separate books posts as one bill per company or organization — routing an entity to a ledger, defaults, the fan-out banner, partially_exported, and what inletAP does not do section: Reference order: 28 navLabel: Posting to several companies --- # Posting to several companies Start with the fact everything else on this page follows from: **A bill belongs to one set of books.** There is no cross-company posting anywhere in the QuickBooks Online API, and none in Xero's either. Every write is scoped to a single company file or organization, and no field on a bill names another one. 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. The same arithmetic applies across ledger kinds: with QuickBooks and Xero both switched on, one approved invoice posts once into each — that is a fan-out too, and nothing here about defaults and routing changes. ## Two different situations, and they are not equally hard | Your setup | What a split invoice becomes | | ------------------------------------------------------- | ---------------------------------------------------------------------- | | One set of books, properties tracked on the line | **One bill.** One line per allocation, each carrying its own property. | | Several companies of one kind, one per ownership entity | **One bill per company.** The fan-out. | 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 property coding on each line — a class in QuickBooks, a tracking option in Xero. Posting three bills into one company would double and triple the payable for a single invoice. The same three partnerships on three separate companies are three bills, because no bill can reach into another company's ledger. So inletAP groups allocations by the **ledger** their entity points at, within each kind. "How many bills?" is always answered by counting distinct ledgers, never by counting entities. ## Mapping an entity to a company Each ownership entity can name the company its bills post to. Connect each company as its own connection in [Settings → Connectors](/app/settings?tab=connectors) and switch **Post approved bills here** on for it. Then route the entity on [Settings → Split coding](/app/settings?tab=split), in the **Ownership entities → ledgers** table. That table has one column per accounting system you have connected, so an entity can name a QuickBooks company and a Xero organization independently. Leaving a column on **Use default** means "send this entity's share to whichever connection of that kind is marked as the default". | Entity names | What happens at export | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A connected company | Its allocations post to that company. | | Nothing | Its allocations post to the **default** company for that kind of ledger — the one marked **Unrouted bills go here**. If no company of that kind is marked as the default, the whole invoice is **parked** with `unrouted_entity` and nothing posts to that kind. | So the default switch is not decoration. With two QuickBooks companies connected, both switched on and neither marked, an entity you have not routed does not fall back to anything: its invoice waits for a person. Mark the default on [Settings → Connectors](/app/settings?tab=connectors). One company of a kind, on its own, is the default by definition and needs no switch. Either way it is reported before you export: the export plan lists the entities that name no ledger of their own, because "posts as 1 bill" when you expected three is a surprise that has to happen before the Export button rather than after it. How many companies may receive bills at once is a plan limit, counted across QuickBooks and Xero together — the [exports reference](/docs/exports-reference) has the numbers. Connecting is never capped; switching **Post approved bills here** on is. 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 split panel on the invoice states what will happen, right where you are still coding it: ``` 2 ownership companies → posts as 2 bills, one per ledger Maple Ct LP ledger …9012 $4,233.34 Elm/Oak JV ledger …4471 $8,246.66 ``` That is the $12,480.00 GreenLeaf invoice from [splitting an invoice](/docs/splitting-invoices): 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 shows no banner at all — one company is the ordinary case, and it needs no warning. The banner appears only from the second company onwards. The banner also carries warnings when the target company cannot do what the coding asks. The first three below are QuickBooks-only — they describe QuickBooks class and location tracking, which Xero does not have: | Warning | What it means | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Class tracking off | The company does not track classes per transaction line, so no property coding can reach the bill. | | Locations only | Properties are modeled as QuickBooks Locations, which are a bill header field. See the next section. The export is **not** blocked: the bill posts with no property coding on its lines. | | Class limit near | QuickBooks Plus caps classes and locations at 40 combined, and this company is close to it. | | Unrouted entity | An ownership entity names no company of its own. Its share goes to the default company where one is marked, and the invoice is parked where none is. | ## 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: the warning is on the banner while you are still coding, because a bill that posts with two of three properties missing is far harder to spot afterwards than a warning is to read now. ## 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. A Xero organization does the same job with different furniture: one ACCPAY bill, one line per allocation, and the property carried as a tracking option on the line. See [connecting Xero](/docs/connecting-xero). ## `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. It does not take a split to reach it: two ledgers switched on will do, because one of them can refuse a bill the other took. The export screen shows one row per destination, with its own status, its own amount, and a link into the bill where one exists. Retry re-runs the batch, and a destination that already holds the ledger's own id is skipped rather than posted again — so a retry of a partly posted document only attempts the one that missed out, and cannot re-post the ones that succeeded. **Retry the whole run** does the same across a run of several batches. See [export failures](/docs/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](/docs/splitting-invoices) — where the allocations come from. - [Exports reference](/docs/exports-reference) — what is written, and how retries avoid a double post. - [Export failures](/docs/export-failures) — including a partial failure across companies. - [Connecting QuickBooks](/docs/connecting-quickbooks) — connecting each company, and switching it on. - [Connecting Xero](/docs/connecting-xero) — the same for a Xero organization. - [Invoice statuses](/docs/invoice-statuses) — where `partially_exported` sits.