ASC 850
Due To and Due From originated as a matched pair at the entity level, balanced by construction, tagged to the counterparty, and posted into each entity's ledger with the same document ID.
Everyone eliminates intercompany at consolidation. Almost nobody originates it correctly at the entity.
Intercompany balances fail to eliminate for a boring reason: the two sides were never created together. One entity pays a bill that belongs to another, the payment posts, and the corresponding Due To gets journalized later — by a different person, in a different workbook, sometimes in a different period.
By consolidation the two sides disagree, and the difference becomes a plug. Every multi-entity group has a version of this, and it is one of the more uncomfortable things to explain in an audit, because there is no clean story for why a balance with yourself does not agree with itself.
Consolidation tooling does not solve it. Those systems eliminate what is already in the ledgers — they read the balances rather than creating them. If the entries were wrong at the entity layer, the elimination inherits the problem.
Enter the terms once. The schedule builds itself, period by period, to the standard.
The Due From in the paying entity and the Due To in the benefiting entity created as a matched pair from one transaction, so they cannot drift apart.
When one entity pays a cost that belongs to another, the payer is selected on the transaction itself and the intercompany bridge is built into the entry rather than journalized afterwards.
A server-side guard rejects an intercompany entry whose two sides do not agree, so the pair balances before it reaches the ledger rather than being reconciled after.
Common-control and consolidating-only entities flagged, so the entries that must eliminate are distinguishable from the ones that must not.
Due To and Due From carried in dedicated accounts by counterparty, so the consolidation elimination clears to zero instead of leaving a plug.
Both sides carry the same document ID back to the originating transaction, so the pair is traceable from either entity's ledger.
Approve once. Post a month at a time — straight into QuickBooks Online, Xero, or Dynamics 365 Business Central, with a document ID on every line and duplicate posting blocked.
Read-only by design. AccelClose never touches cash, vendors, or payments. It reads your ledger and writes journal entries you have already approved — nothing more.
Consolidation tools eliminate intercompany balances at the reporting layer — they net out what is already in the ledgers. AccelClose originates the entries at the entity layer, so the balances exist correctly in each entity's books in the first place. Eliminating a balance and creating it are different jobs, and most tooling only does the first.
Because the two sides get created separately, by different people, at different times, sometimes in different periods. One side is journalized when someone notices; the other is journalized when someone else notices. Originating both sides from one transaction removes the failure mode rather than reconciling it.
When one entity pays for something that belongs to another, you select the paying entity on the transaction itself. The Due To and Due From legs are then built into the entry automatically, instead of being remembered as a separate month-end journal.
Yes — an allocated cost is an intercompany transaction like any other, with the expense landing in the entity it belongs to and the intercompany bridge carrying the funding side.
QuickBooks Online, Xero, and Dynamics 365 Business Central are live and posting today. Sage Intacct works today through ERP-formatted CSV import and export, and any other ERP works the same way.
Summarized for general information. Entity structure, common-control determinations, and transfer-pricing considerations remain yours to determine.
Try the free interactive demo — no signup — or start a 30-day trial and connect your ledger.