Organizations that run multiple entities, properties, or funds eventually hit a category of invoice that doesn't fit the normal AP mold: the intercompany invoice. One entity bills another inside the same organization, and the transaction has to be processed, coded, and reconciled — but it isn't a third-party vendor bill, and treating it like one causes problems.
The instinct is to drop intercompany invoices into the same queue as everything else. That's where the trouble starts. They arrive in a different format, from a different source, and they need a different reviewer's eyes — so when they're mixed into the main flow, they get mishandled, miscoded, or simply lost in the pile.
The cleaner design is a dedicated intercompany queue: a separate lane that keeps these invoices visible, correctly handled, and reconciled — while reusing the AP machinery you already have everywhere it makes sense.
What makes intercompany invoices different
Three things set them apart from standard vendor invoices, and each is a reason not to blend them into the main queue:
- They arrive through specific channels. Intercompany invoices typically come in by email or manual upload, and often in a structured format such as Excel — not as scanned PDFs from an outside vendor. The capture path is genuinely different.
- They're internal, not third-party. These represent transactions between parts of the same organization. The review questions — and the people who should answer them — aren't the same as for an external supplier bill.
- They're easy to lose in volume. When a handful of internal invoices sits inside hundreds of vendor invoices, they don't get the distinct attention they need. A separate queue keeps them from disappearing.
The design: a separate queue, the same engine
The right balance is to isolate intake and review, but reuse processing. You don't want a parallel system — you want a clearly marked lane inside the system you already run.
In practice:
- A dedicated entry point. Intercompany invoices get their own option in the AP interface — distinct from the standard invoice flow — so the user explicitly chooses to work in that context.
- Upload or work the email channel. From there, the user can either upload an intercompany invoice directly or pick up one that arrived through the email channel. Both paths feed the same queue.
- A separate intercompany queue. This is the heart of it. Intercompany invoices live in their own queue, separate from regular vendor invoices, so they're never buried and always have a clear owner.
- The same review screen everyone already knows. Once an intercompany invoice is in the queue, it opens in the familiar split-screen view — the document on one side, header and line detail on the other. No new interface to learn; the only thing that changed is which queue the work came from.
The payoff of this approach is that the downstream integration doesn't change. From a high level, an intercompany invoice follows the same process a regular invoice follows once it's been reviewed — so the export and ERP-posting layer needs no special handling. You get the operational separation where it matters (intake and review) without fragmenting the part of the pipeline that's already working.
Why this matters for property and multi-entity finance
For property-management and public-sector finance teams managing multiple entities or properties, intercompany activity is constant — shared services billed across properties, costs allocated between funds, internal charges that still have to be coded and reconciled accurately.
A dedicated queue gives that activity:
- Visibility — intercompany items are never lost inside the vendor-invoice flow.
- Correct ownership — they route to the people who understand internal transactions, not the general AP pile.
- Auditability — a clear, separate trail of intercompany processing is exactly what reviewers want to see when entities are reconciled.
And because the processing engine is shared, none of that comes at the cost of maintaining a second system.
Where EZ Cloud fits
EZ Cloud handles intercompany invoices through a dedicated queue that keeps them separate from your standard vendor flow while reusing the same review screen and the same downstream processing. Intercompany invoices can come in by email or manual upload — including structured formats like Excel — and they're worked in the familiar split-screen interface your AP team already uses, with no change required to the integration layer.
A US housing authority runs intercompany processing this way alongside its standard AP in production — the broader picture is in our HACOV case study, and how the processed invoices flow into Yardi Voyager is covered on our Yardi integration page. For teams where supplier email is its own source of friction, our AI email exception prevention layer takes that work off the queue before it ever reaches a human.
If intercompany invoices keep getting lost in your main AP queue, the fix isn't more discipline — it's a separate lane. Give them their own queue and the rest of the pipeline can stay exactly as it is.