Intercompany Invoicing and Reconciliation in D365: Auto Posting, Due To and Due From, Eliminations

In the pricing article I left the transfer price sitting on the intercompany sales order line and the matching cost on the purchase order line. That is where most projects stop paying attention, and where the finance team's problems begin. Today I follow the chain through posting: how the invoice in the selling company creates the invoice in the buying company, where each side lands in the ledger, why the due to and due from accounts are not where you reconcile trade, and what period end has to do before anyone can eliminate anything.

TWO INVOICES FOR ONE DELIVERY

An intercompany delivery is one physical movement and two commercial documents. In the selling company the intercompany sales order (the ICS order, in the naming from the order chain article) is packing slip updated and invoiced like any other sales order: inventory is issued, revenue and cost of goods sold post, and the intercompany customer gets an open transaction. In the buying company the intercompany purchase order (the ICP order) needs a product receipt and a vendor invoice, and D365 can create both for you.

The automation lives on the trading relationship from the trade setup article. The purchase order policies hold the two switches that matter: post the product receipt automatically when the intercompany packing slip posts, and post the vendor invoice automatically when the intercompany sales invoice posts. A companion option lets the product receipt carry the packing slip number and the vendor invoice carry the sales invoice number. Switch it on: it turns reconciliation from a hunt for matching amounts into a join on a document number.

The automatic posting runs in the buying company in the context of the user who posted the sales invoice. That sentence explains a surprising number of support tickets: the user needs rights in the buying legal entity, the fiscal period there must be open, and the vendor posting profile and inventory posting for the intercompany vendor must be complete, or the sales invoice posts and the purchase side quietly does not. The first symptom is a customer balance in one company that nobody can find in the other.

WHAT EACH SIDE POSTS

• Seller, invoice: debit the intercompany customer summary account from the customer posting profile, credit revenue, debit cost of goods sold, credit inventory at issue cost. Transferred charges post as charge revenue here too.

• Buyer, product receipt: debit inventory, credit the purchase accrual. An unmatched receipt therefore shows up as an accrual balance, not a vendor balance.

• Buyer, vendor invoice: reverse the accrual, debit inventory at the invoice amount including charges, credit the intercompany vendor summary account. On standard cost items the gap between transfer price and standard lands in purchase price variance.

The design decision that pays off most is to give intercompany trade its own main accounts. Create an intercompany customer posting profile and an intercompany vendor posting profile, assign them through customer and vendor groups, and in inventory posting use the group relation so intercompany revenue, cost of goods sold, and purchase expenditure post to dedicated accounts. When you later build elimination rules you want an account that contains nothing but intercompany activity; if intercompany revenue shares an account with external revenue, every elimination becomes a calculation instead of a rule.

A cheaper habit with the same payoff is a financial dimension for the trading partner, defaulted from the intercompany customer and vendor records, so a trial balance can be filtered by partner company.

DUE TO AND DUE FROM: WHAT INTERCOMPANY ACCOUNTING IS FOR

This is the misunderstanding I meet most often. General ledger has a setup called intercompany accounting, where for each pair of legal entities you define the due to account, the due from account, and the journal names on each side. People read the name and assume it controls intercompany trade. It does not. It applies when a general journal line in one company has its offset in another: a recharged expense, a cash transfer, a cross-entity correction, or a centralised payment. In those cases D365 posts the line in each company and balances both sides with due to and due from automatically.

Intercompany sales and purchase orders never touch those accounts. They post through the customer subledger in the seller and the vendor subledger in the buyer, like external trade. When someone says due to and due from do not agree with the trade volume, the answer is that they were never meant to. Trade reconciles between accounts receivable in one company and accounts payable in the other; due to and due from reconcile between themselves across the two companies, and should move only through journals.

The two worlds meet at settlement. The buyer can pay through the bank, or you can net the balances with an intercompany journal: in the buying company, debit the intercompany vendor and offset the intercompany customer in the selling company. With intercompany accounting set up, the journal balances through due to and due from, and both subledgers receive settlements that close the invoices. Settle by document number rather than oldest open item, or ageing on both sides stops meaning anything.

PERIOD END: THE SEQUENCE THAT PREVENTS MOST DIFFERENCES

Reconciliation is easy when posting was disciplined and miserable when it was not, so most of the routine is finishing the posting before anyone compares numbers.

1. Match deliveries: list intercompany packing slips in the seller without a product receipt in the buyer. With automatic receipt posting on, this is empty unless the receiving warehouse runs Advanced WMS and the receipt is waiting for work.

2. Finish invoicing: post all intercompany sales invoices for shipped lines, then open pending vendor invoices in the buyer filtered to intercompany vendors. Anything there is an automatic invoice that failed.

3. Compare the intercompany customer balance in the seller with the intercompany vendor balance in the buyer, per currency, as of the period end date. Do it in transaction currency first.

4. Explain the remainder: in-transit shipments posted on the last day and received on the first, revaluation at different rates or dates, charges on one side only, credit notes in the seller with no purchase credit in the buyer, and manual postings to the summary accounts.

5. Settle or net the agreed balance.

6. Eliminate in the consolidation company.

There is no standard report in Finance and Operations that lines up each intercompany sales invoice against the purchase invoice on the other side. What I build instead is a simple query: customer transactions for the intercompany customer in company A, vendor transactions for the intercompany vendor in company B, joined on invoice number (which is why the shared numbering option matters), with a difference column. Run it weekly: a difference found after three days takes ten minutes, the same difference at quarter end takes an afternoon.

ELIMINATION BASICS

Consolidation happens in a separate consolidation legal entity, populated by online consolidation or imported balances. Elimination rules are defined against that company: each names a source account or range and a destination, and generates a proposal you review and post. For trade, the standard rules eliminate intercompany revenue against intercompany cost of goods sold, and the intercompany receivable against the intercompany payable. If those four streams have their own main accounts, the rules are a one-time setup; if not, you adjust the proposal every month by the external portion of the balance.

Unrealised profit in inventory is the elimination the rules cannot do. If the seller shipped at cost plus twenty percent and the buyer still holds half the goods, group inventory is overstated by the markup on that half, and D365 does not connect the two facts. The practical answer is a calculated journal: take intercompany inventory on hand in the buyer (the partner dimension helps), apply the markup percentage, post an entry that reduces inventory and cost of goods sold, and reverse it next period. Document the calculation, because the auditor will ask.

The consolidation company only sees balances. If the trading companies disagree by a thousand, the rule leaves a thousand hanging and someone books an unexplained adjustment. Steps one to four are what make the elimination clean.

WHAT GOES WRONG

• The automatic vendor invoice fails because the posting user has no rights in the buying company, the period is closed there, or a posting profile is incomplete, and nobody notices until the balances disagree.

• Intercompany revenue and cost share accounts with external trade, so elimination rules cannot be used and every month is a manual calculation.

• Charges are added on the sales order but not transferred, so the seller's receivable stays higher than the buyer's payable.

• A credit note is posted in the seller without a matching purchase credit in the buyer, which is the subject of the next article.

• A manual journal hits the customer or vendor summary account directly, breaking the ledger to subledger reconciliation as well.

Before closing the first period with intercompany trade live, confirm: automatic receipt and invoice posting on and tested in both directions, shared document numbering, dedicated intercompany posting profiles and inventory posting accounts, a partner dimension defaulting from the master records, intercompany accounting for every pair of companies that post journals to each other, a weekly matching query joined on invoice number, and elimination rules that point only at intercompany accounts.

Next time I will look at intercompany returns and credit notes: how a return order in the buying company flows back as a return in the seller, when a credit note alone is enough, and how disposition codes and arrival behave across entities.

In this series: previous article Intercompany Pricing in D365: Where the Transfer Price Comes From and Who Owns the Margin