Journal Entries & Estimates
Topside entries: what they are, with a worked example
A topside entry is a manual adjustment made to consolidated numbers, outside the entity ledgers, usually after those ledgers have closed. It sounds like a way around the books. Done properly, it's the opposite: the way a group gets its reported numbers right when an entity's books are already locked.
Where reported numbers actually come from
A group's financial statements aren't any one ledger. They're built in the consolidation: each entity's ledger, plus the intercompany eliminations, plus any adjustments made at that level. So a topside entry made in the consolidation does end up in the published numbers.
That's allowed because GAAP cares whether the reported number is right, not which system an entry sits in. A topside entry is a choice about where to record something, not an accounting method. When it makes the reported numbers correct, it's legitimate. When it makes them wrong, it's how several well-known frauds were done: unsupported entries made at the corporate level after the books closed.
What counts as one
Intercompany eliminations are usually a separate category. They're what makes intercompany sales and balances disappear on consolidation, they recur for a mechanical reason, and many ERPs post them automatically to an elimination entity. Most people don't call those topsides. The entries that do get the name are late corrections made in the consolidation instead of the entity's books, reporting-level reclassifications, and audit adjustments that were never pushed down to the entity that caused them.
How often you'll see them depends on the setup. A small group with two or three entities in one ERP may never have one: something late gets fixed by reopening the period. They're common where a separate consolidation system sits above several ledgers that close on different days.
A worked example: a cutoff error found after the ledger locked
A subsidiary invoices a customer $42,000 on August 31. The goods cost $25,000. They don't ship until September 2, and the terms are FOB shipping point, so control passes to the customer when the goods ship. Under ASC 606 that makes it September revenue. The subsidiary booked it in August anyway.
Corporate catches it during the consolidation review. By then the subsidiary's August ledger is locked, and the group's reporting deadline doesn't leave time to reopen it.
The options, best first
- Reopen the subsidiary's August period and fix it there. The ledger and the reported numbers stay in agreement. This is the cleanest answer when there's time.
- If the amount is immaterial, correct it in the subsidiary's September ledger and document why. August stays slightly overstated, which is only acceptable because it doesn't matter to anyone reading the statements.
- If it's material and the ledger can't be reopened, record a topside entry in the consolidation, then push the correction down into the subsidiary's books afterward.
Here it's material and the deadline is fixed, so it's option three.
The topside entry, August
| Account | Debit | Credit |
|---|---|---|
| Revenue | 42,000 | |
| Accounts receivable | 42,000 | |
| Inventory | 25,000 | |
| Cost of goods sold | 25,000 |
It reverses one specific sale, line by line, not a net figure. Revenue and cost both come out, the receivable comes off, and the goods go back into inventory because they were still in the building on August 31. It takes revenue out: the topside corrects an overstatement rather than creating one.
| August, consolidated | Ledgers | After topside | Change |
|---|---|---|---|
| Revenue | 1,180,000 | 1,138,000 | (42,000) |
| Cost of goods sold | 708,000 | 683,000 | (25,000) |
| Gross margin | 472,000 | 455,000 | (17,000) |
| Accounts receivable | 960,000 | 918,000 | (42,000) |
| Inventory | 640,000 | 665,000 | 25,000 |
The subsidiary's own ledger still shows the sale in August. Only the consolidated numbers are corrected, which is why the push-down matters later.
What happens in September
The subsidiary's ledger has nothing for this sale in September, because it already booked it in August. The revenue still has to land in September's reported numbers. Most consolidation systems work on year-to-date balances, and on that basis it happens without a second entry: year-to-date through September, the ledger correctly includes the sale, the August topside applied only to August, and September's month is year-to-date September minus year-to-date August. If a system works on monthly amounts instead, someone posts the opposite entry in September. The result is the same.
| Revenue | August | September | Movement |
|---|---|---|---|
| Subsidiary ledgers | 1,180,000 | 1,240,000 | 60,000 |
| Effect of the topside | (42,000) | 42,000 | 84,000 |
| Reported | 1,138,000 | 1,282,000 | 144,000 |
What this does to flux
Run flux on the ledgers and revenue is up 60,000. The reported number moved 144,000. The 84,000 difference is this one sale, taken out of August and landing in September, and it isn't in any ledger account. Gross margin shows the same thing: up 24,000 in the ledgers, 58,000 as reported. Commentary written from the ledgers would be complete and still miss most of the reported movement.
Two habits follow. Run flux on the numbers that actually get reported, or reconcile the ledgers to them first. And when a topside entry fixes one month, write down what happens to the next month at the time you make it.
How it goes wrong
The same mechanics run the other way are the problem. A topside entry that adds revenue or removes expense, with no transaction behind it, inflates the reported numbers while every entity ledger looks clean. That's why auditing standards on fraud tell auditors to test entries made at period end, after the close, and outside the normal ledger. Most topside entries are legitimate. The controls around them have to be deliberate, because the ones built into the ledger don't apply. The one that causes trouble is often not the largest: it's a small adjustment someone made once with a good reason, that now gets copied forward every month and that nobody has asked about since.
What to check on every topside entry
- Why it isn't in the ledger. "The period was locked and the deadline was fixed" is a reason. "It's easier this way" isn't.
- Support. The same documentation a ledger entry would need: the transaction, the calculation, the date it was found.
- Every side of the entry. A cutoff correction moves revenue, cost, receivables and inventory, not just revenue.
- Who made it and who approved it. Two different people, with the approval recorded.
- What happens next month, and when the correction gets pushed down into the entity's books.
- Whether it recurs. The same topside entry three months running means the ledger is wrong at the source. Fix it there.
Every period, the ledgers plus the eliminations plus the topside entries should equal the reported numbers, line for line. If that reconciliation doesn't exist, it's the first thing to build.
Most of this surfaces again at flux review. The free flux template flags which balances moved enough to explain. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.
Related: reclass vs adjusting entry, late entries after commentary is written, and reversing entries.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.