Core Close Activities: Part 4

2026-09-08

Elimination: when a sale never actually left the group

A parent selling goods to its own subsidiary books a perfectly ordinary-looking sale in its standalone accounts, receivable, revenue, the works, and the subsidiary books an equally ordinary purchase. Legally, two separate companies did business. From a consolidated perspective, though, the group is a single entity, and moving goods from one pocket to another inside the same entity was never a sale at all: if the goods are still sitting unused in the subsidiary's warehouse at period-end, the group's true revenue hasn't moved, because nothing has actually left the group.

Consolidation eliminates the whole transaction in that case, the parent's revenue and the subsidiary's corresponding cost both disappear, because nothing genuine happened yet from the group's point of view.

The harder case is once the subsidiary actually uses those goods and sells the finished product to a real, external customer. Say the parent's own cost to produce the goods was ₹7,00,000, it sold them to the subsidiary for ₹10,00,000 (a ₹3,00,000 intercompany margin), and the subsidiary then sold the finished product to an outside customer for ₹15,00,000.

The elimination entry needs to do two things at once: remove the full intercompany sale from revenue (₹10,00,000, since none of that was a sale to anyone outside the group), while restoring only the genuine cost to the group's cost of goods sold, not the subsidiary's inflated, intercompany-priced cost:

After this: revenue = ₹25,00,000 − ₹10,00,000 = ₹15,00,000 (matches the genuine outside sale); cost of goods sold = ₹10,00,000 − ₹3,00,000 = ₹7,00,000 (matches the parent's genuine production cost); profit = ₹8,00,000. Only the ₹3,00,000 intercompany margin, the "unrealized" profit sitting inside the subsidiary's cost basis, needed removing, not the full ₹10,00,000, because the underlying goods genuinely left the group this time.

Reconciliation: why "it's probably just timing" doesn't apply here

A bank reconciliation mismatch defaults to a timing explanation because the two sides, the company's own books and the bank's, are genuinely independent systems; no single mistake can land on both sides at once. Intercompany reconciliation doesn't get that same presumption, because both sides of the mismatch usually sit inside the same group, often maintained by overlapping finance teams. A single error, or a coordination failure, really can show up on both, or neither, side.

A parent recording a ₹10,00,000 intercompany sale while the subsidiary records only ₹9,50,000 as the corresponding payable isn't automatically a timing gap the way a bank reconciliation mismatch would be. If the ₹50,000 gap traces back to the subsidiary's purchasing team working off an outdated quotation that the parent had since revised upward, without ever being told, that's not timing at all. It's the same failure pattern already established for cut-off memos: a decision was made on one side, and the update never reached the side that had to execute against it. The fix is the same too: an explicit, confirmed communication whenever intercompany terms change, not a hope that both sides will independently land on the same number.

A transit gap that turns out not to be a genuine gap

A parent shipping goods to its subsidiary under FOB Shipping Point terms recognises the sale the moment goods leave its own gate, the same rule established for external sales. If the subsidiary's own rule is "record the purchase only once goods physically arrive," and the goods are still in transit at period-end, the two sides won't match: the parent shows a receivable, the subsidiary shows nothing yet.

The Intercompany Matrix, and why the account's name never decides elimination

Whether goods sit in a warehouse as ordinary Inventory or in transit as Goods-in-Transit, the elimination decision doesn't depend on which account they're sitting in, it depends on one question only: is the value still inside the group, or has it left to a genuine outsider? As long as goods are still between two group companies, the full intercompany transaction eliminates, regardless of what the holding account happens to be called.

Tracking this across an entire group, not just one pair of companies, but five or six, transacting with each other constantly, needs its own register, structured as a matrix: every company as both a row and a column, each cell showing what that row-company sold to that column-company. Matching pairs (X-to-Y against Y-to-X) get checked and eliminated together at consolidation. An empty or incomplete cell surfaces a completeness gap before consolidation even starts, exactly the way the accrual register and fixed asset register surfaced their own completeness gaps earlier in this study.

Settlement itself often uses the same matrix logic in reverse, at a portfolio level: rather than every pair of group companies wiring money to every other pair, a netting cycle nets each company's total receivables against its total payables across the whole group and settles only the resulting net position. Three group companies owing ₹5,00,000, ₹3,00,000, and ₹2,00,000 between them in a triangle would otherwise need three separate transfers moving ₹10,00,000 gross; netting reduces that to a single net obligation of ₹3,00,000 actually needing to move, with the rest settling on paper. For a genuinely cross-border group, this also means far fewer currency conversions, a direct link into the FX section that follows.

Transfer pricing: consolidation's lens and the tax authority's lens don't agree

The ₹3,00,000 intercompany margin eliminated earlier disappears entirely from the group's consolidated statements, as far as a shareholder is concerned, it never existed. But no tax authority ever looks at a consolidated statement; each one only ever sees the standalone filing of the entity within its own borders. If the parent operates in a higher-tax country and deliberately prices its intercompany sale close to its own cost, cutting the margin from ₹3,00,000 toward zero, its own reportable profit, and therefore its own tax bill, genuinely falls in that country, while the subsidiary in a lower-tax country buys more cheaply and keeps the margin as its own, lower-taxed profit instead. The group's total tax bill falls, purely from where the margin was allowed to land, even though the shareholder's consolidated number never moved.

This is exactly why transfer pricing regulations exist: tax authorities require related-party pricing to sit at what's called the Arm's Length Price, the price two genuinely independent, unrelated parties would have agreed to in the same deal, tested against comparable market transactions or a company's own margin pattern with genuine third parties. The relationship between the two companies can be as close as a parent and its wholly-owned subsidiary; the price between them still has to behave as if it wasn't.

Three rates, three different moments

A $10,000 export invoiced on 15 July, when USD/INR sat at ₹83, books at ₹8,30,000, the transaction rate, applied once, at the moment the event happened.

This period-end retranslation, using the closing rate, produces an unrealized gain or loss, a mark-to-market estimate of what the balance is worth right now, with no cash having actually moved. If the customer eventually pays on 10 August at ₹84, the cash received (₹8,40,000) gets compared against the balance actually carried at that point (₹8,50,000), not the original ₹8,30,000, a further ₹10,000, this time a realized loss, because real cash has now genuinely changed hands at the settlement rate. Across the whole life of the receivable, the two moves net out exactly to the rate's overall change from start to finish (₹83 to ₹84, a ₹10,000 net gain over the period), the unrealized-then-realized split only decides which period each piece lands in, not the total.

Monetary versus non-monetary: what actually moves with the rate

Not everything denominated in a foreign currency behaves the way a receivable does. A machine bought outright for $50,000 on 1 June at ₹82 (₹41,00,000, paid in full that same day) sits on the books at that value permanently, regardless of where USD/INR later moves, it never retranslates.

The distinction is about what the balance's "worth" is still tied to. A receivable's worth is tied to a future amount of cash still to be collected, and that cash claim is itself denominated in dollars, so its rupee worth genuinely changes as the rate moves. A machine, once bought and paid for, has no remaining tie to a future cash flow at all; its value from that point on depends only on its own use, depreciation, or impairment, the same rules that would apply whether it had been bought in dollars or rupees.

When the cash has already settled: advance payments

A new machine order, $20,000, paid entirely in advance on 1 July at ₹82 (₹16,40,000), with delivery not due until 15 August, raises a genuinely easy trap.

Hedge accounting: matching the exposure to its offset

A forward contract locking a future USD receipt at a fixed rate, ₹86/USD, say, regardless of where the market actually lands on settlement day, doesn't merely soften the exposure to rate movement; a full-cover forward removes it entirely, because the outcome no longer depends on the rate at all. Accounting for this pairs the hedge instrument's own gain or loss against the underlying exposure's gain or loss, so the two roughly cancel and the net P&L impact stays close to zero, the same matching-principle logic already seen in contra-revenue accounts, now applied to currency risk rather than sales.

Why a manual entry is a different kind of risk

Every entry seen through most of this study traced back to a register, a schedule, or a defined calculation, the accrual register, the fixed asset register, the payroll register. A manual journal entry, typed directly into the GL with no register behind it, "Dr Cost of Goods Sold ₹3,50,000 / Cr Inventory ₹3,50,000," description: "Year-end adjustment," has no such trail. Structurally it looks identical to a depreciation posting, but a depreciation entry can always be traced back to a defined process; this one can only be traced back to whoever typed it, at whatever moment they chose to type it. That absence of a built-in process is exactly what makes manual entries the highest-risk category in a close cycle, even though genuine, legitimate manual entries are unavoidable.

Segregation of duties, and why an emergency override isn't a legitimate escape hatch

A policy requiring a different person to prepare and approve every manual entry is the same maker-checker principle already built for reconciliations, applied here because, unlike a register-based entry, nothing else is checking the number.

That policy only works if the approval is genuine. A preparer with their own "Emergency Override" access, used to approve their own entry when the designated approver is unreachable near a deadline, satisfies the letter of a two-step process, a button genuinely got clicked, while breaking its entire purpose: no independent person ever actually looked at the entry.

What a manual entry needs to carry before anyone can trust it

A bare "Year-end adjustment" description gives an approver nothing to verify against, only trust. The same evidence discipline built for reconciliations applies here: a specific business reason (not a vague label), the underlying calculation or source document, the preparer's name and date, and, for material amounts, a senior sign-off confirming the situation has genuinely been investigated rather than simply written off. An entry booking a ₹3,50,000 inventory write-off for stock that went missing during a physical count, for instance, needs the inventory reconciliation report showing the count-versus-system gap, a confirmation from whoever physically searched and found nothing, and a senior approval confirming this is genuinely a write-off rather than something that needs investigating for fraud or process failure first.

Patterns across many entries, not just risk within one

A single ₹95,000 manual entry, safely under a ₹1,00,000 threshold that would otherwise route a copy to the CFO, is unremarkable on its own. Eight such entries, all exactly ₹95,000, all posted by the same preparer on the same day, stop being unremarkable the moment they're looked at together, a pattern that reads as a single, larger amount deliberately broken into pieces specifically to stay under a review threshold, a recognised pattern called structuring or threshold splitting.

Recurring and auto-reversing entries: manual JE risk, deliberately avoided

A recurring journal entry template, set up once, posted automatically every period without anyone retyping it, sits closer to a register-based entry than a manual one, because the number no longer comes from anyone's in-the-moment discretion once the template exists.

Auto-reversal (a system flipping an accrual automatically at the start of the next period) reduces manual-JE exposure the same way, since the reversal itself needs no human typing. A company choosing manual, invoice-triggered reversal instead, because invoices can arrive up to three months late, and reversing every month regardless would mean re-booking the same estimate repeatedly, makes a real, defensible operational trade-off, but it's worth being precise about what that trade-off actually costs: every one of those manual reversals is, by definition, a manual journal entry, carrying the full documentation and segregation-of-duties burden this section just built. Choosing manual reversal for operational efficiency means manual-JE discipline matters more there, not less, simply because more manual entries flow through that specific process than a company using auto-reversal would have.

Three paths, and the order they have to be decided in

Something surfacing after close and after reporting needs its category settled before its treatment can be decided, and the two decisions happen in a specific order: first, is this a genuine estimate change or an error; only if it's an error does a second question, material or immaterial, decide what actually happens.

• Estimate change (a judgement that was reasonable when made, now updated with new information): prospective only, nothing about prior periods touched.
• Error, immaterial: a simple, current-period entry in the next open cycle, no restatement machinery involved at all.
• Error, material: the full retrospective mechanism, restated comparatives, a third balance sheet if needed, and the cumulative effect landing in opening retained earnings, never in the current period's own profit and loss.

Why a locked period stays locked

Once a period closes, most systems mark it locked, no entry, by anyone, at any seniority, can post directly into it without a deliberate, logged unlock. A junior accountant instinctively trying to post a July-dated entry for something discovered in August, simply because "it's a July issue," should be rejected by the system itself, not merely discouraged by policy. The same logic already built for segregation of duties applies here: a control that depends only on someone remembering the right training isn't really a control, because memory fails and habits default to the familiar path. A technical barrier doesn't depend on anyone's memory or good intentions.

Some companies maintain a dedicated adjustment period (sometimes called a "Period 13") specifically for the rare, genuinely material corrections that surface after close, but this is a new, current period, not a reopening of the locked one. An entry posted there for a material error still carries only the retrospective-restatement formula's net cumulative effect, booked directly against retained earnings, never the full original error amount re-entered as a fresh expense, and never a direct edit inside the original locked period.

Three types of adjustment, three different risk profiles

When the same gap keeps coming back

A ₹15,000 intercompany gap in one month, correctly handled as an immaterial post-close entry, is unremarkable on its own, and so is a similar gap the month before, and the month before that. Several months running of the same kind of gap, though, isn't the same signal as structuring or threshold splitting from the journal-entries discussion, there's no clustering around a review threshold here, no sign anything was deliberately kept small. What it signals instead is closer to the escalation logic built back in close calendar and ownership: a root cause, not a coincidence. If the same category of mismatch keeps surfacing after close, the process step meant to catch it, the intercompany reconciliation itself, isn't actually catching it before close, and no amount of correctly handling each individual instance afterward fixes that. The right response moves upstream: strengthening the pre-close intercompany confirmation step on next cycle's close calendar, and naming someone specifically responsible for clearing the group's intercompany matrix before the reconciliation deadline, rather than leaving it to surface as a predictable line in every month's post-close adjustments.

All fourteen items are now covered, and one thread from the very first part is worth closing properly rather than leaving open indefinitely: whether finding the same cut-off pattern across ten separate invoices, all from the last two days of a period, all with gate registers dated a few days into the next one, should be read differently from a single isolated case. It should, and for the same reason a recurring intercompany gap and a cluster of near-identical journal entries both turned out to matter more than their individual amounts suggested. A single late invoice is ordinary human error, scattered and unremarkable. Ten, all pulled in the same direction, all landing right at the period boundary, stop looking random the moment they're looked at together, the same signature structuring left in the journal-entries discussion, just wearing cut-off's clothes instead.