Munshi ICE: intercompany eliminations, computed

Sounds familiar?

The intercompany frustrations Munshi ICE was built to end.

• Intercompany out of balance at close
• Eliminations that don’t net to nil
• The same reconciliation rebuilt every quarter in Excel
• Unmatched intercompany invoices
• Seller and buyer booked it differently
• GST on one book, not the other
• TDS differences on balances
• Goods in transit at period end
• Late debit and credit notes
• One payment covering many invoices
• FX differences on USD subsidiaries
• Different charts of accounts across entities
• SAP in one company, Tally in another
• Unrealised profit in closing stock
• Intercompany margin in fixed assets and CWIP
• Plugs and write-offs to force it to balance
• Disputes chased over email
• Manual elimination journals
• Related party schedules that don’t agree to the books
• “Show me how this ties” from the auditor
• No audit trail behind the number
• The workbook only one person understands
• Close held up by intercompany
• Board pack figures that change after circulation
• Audit committee asking about related party transactions
• Consolidated results due on a date that does not move

Don’t just post intercompany eliminations into a tool. Compute them.

Most tools give you a place to type the elimination someone worked out in a spreadsheet. Munshi ICE works it out from both books, line by line, shows you why, and waits for your approval.

Why it takes weeks by hand

Two books, one transaction, and a dozen reasons they never agree. A group with manufacturing, trading and overseas subsidiaries does not have an intercompany problem. It has hundreds of small ones, each with a different cause. Munshi ICE names the cause of every one.

• Indirect tax on one side only. The seller books income net; the buyer books cost gross of GST or VAT. Munshi ICE compares like with like, at each pair’s own rate.
• Goods in transit at period end. Invoiced in the last days, not yet received. Identified, checked, and given its own entry instead of sitting in the difference.
• Stock and capital, not expense. The buyer books to inventory or CWIP. The unrealised margin comes out of closing stock, and out of fixed assets and their depreciation.
• One line, many invoices. Three invoice numbers on one goods receipt. Munshi ICE ties it to the right invoices, or says why it can’t.
• Credit notes and reversals. Put where they belong before the two books are compared, so a cancelled invoice is never reported as a difference.
• Withholding tax and currencies. TDS deducted by the payer, and subsidiaries in USD or EUR, compared in the transaction currency at the right rate for the P&L and the balances.

How a year-end runs

1. Start the period. Open the year-end and Munshi reads every company’s ledger lines and open receivables and payables, over the same read-only connections FINAHQ uses, or from a books file. Every pull is a version, tied to the trial balance. An unmapped account stops the run; Munshi never guesses a mapping.
2. Who is in the group. Tell Munshi once which parties are group companies. It remembers them next quarter.
3. How your group eliminates. Say it in plain words: on a lead entity or an intercompany control account, what happens to GST the buyer can’t claim, and who to leave out of this run.
4. Munshi reconciles. Every pair, both ways: the P&L, the balance sheet, stock and capital purchases, and goods in transit.
5. Read what is wrong. Every difference split into what it is made of, with its reason and who must fix it. Not sure what a flag means? Ask the step, in your own words.
6. The calls only you can make. Stock still on hand and the seller’s margin, you enter. Approve a match Munshi could not choose alone, or move a pair’s difference to the account it belongs in. Every change is logged with your name.
7. Approve the journal. P&L and balance sheet eliminations, each Dr = Cr. Nothing posts until a person approves.
8. Download the working paper. For the file and the auditor.

How it matches

Six matching engines, in a fixed order, so the same data gives the same answer every time. Every line is taken through the engines in turn, and each engine sees only what the ones before it left. No guesswork and no AI in the match: when more than one answer fits, Munshi ICE stops and asks a person. You see which engine matched each line, and exactly why the rest did not.

Four reconciliations, each on its own terms

• P&L pairs. One seller, one buyer, one way: the seller’s income line by line against the buyer’s expense, stock and capital lines, net of GST.
• Balance pairs. Each book’s open items at period end, tagged opening, P&L invoice, payment or on account, so each book ties and every difference has a reason.
• Stock and capital purchases. When the buyer books to inventory or capital work in progress, the unrealised margin comes out of closing stock, or out of fixed assets and their depreciation.
• Goods in transit. Invoices in the last days of the period that the buyer has not yet booked, checked before they are called goods in transit.

Related party disclosures

The related party note, from pairs that already tie. The schedules come from the same reconciled pairs as the eliminations, so there is no second spreadsheet beside them. Each related party’s transactions by nature and its closing balances are agreed between both books before they reach the note, and every amount opens to the invoices behind it.

• Sales, purchases, services and capital items, per related party
• Closing receivables and payables, with the reason for any gap
• Standalone and consolidated views from one dataset
• Quarter by quarter, tied to the year to date

Board-level reporting

The board sees consolidated results; the audit committee reviews the related party transactions. Both are only as good as the intercompany work underneath. Munshi ICE finishes that work first, so what goes into the board pack is reconciled, eliminated and approved, with nothing left to change after it is circulated.

• A one-page conclusion: every difference split into its parts and tied, signed off by a named person
• The related party transactions the audit committee reviews, from the same reconciled pairs
• The schedules behind the half-yearly related party disclosure a listed company files
• Quarter by quarter, so the board sees the same figures the auditor will test

Audit working papers

One download for the file and the auditor. Every figure on the screen is in the Excel working paper, and every summary figure is a SUMIFS on a base sheet of the ledger lines. The workbook opens with the conclusion and ends with the configuration exactly as it was applied.

• The conclusion. The difference split into its parts and tied; the P&L and balance sheet bridges; the journal; each pair’s tie; the GST and TDS rates; sign-off.
• The evidence. Every line of every pair with the engine that matched it, its share of the difference and who must act. Filter the bucket and the part column sums to the difference.
• The balances. Each book rolled forward from opening to closing, and the closing balance invoice by invoice, both books side by side: the list to send a company.

Its sheets: index, P&L summary, P&L by quarter, P&L reconciliation, goods in transit, balance sheet summary, reconciliation, roll-forward and by invoice, balance actions, journal lines, margins, the two base sheets of ledger lines, and the configuration.

Control

Munshi does the work. Your team keeps the judgement.

• Nothing posts by itself. The elimination journal waits for a person’s approval.
• Every setting is a person’s. Nothing is pre-filled. Each setting is kept with who set it and when, and carries to the next period.
• Every pull is a version, each with its lines, its trial balance check and the changes from the one before.
• Lock the month. Runs, moves and approvals stop, on screen and on the server. Downloads stay open.

Inside FINAHQ, or on its own

Munshi ICE is part of the FINAHQ close and consolidation, run by Munshi, where its journal flows straight into the group accounts. It is also deployed on its own, for a group that consolidates elsewhere and needs the intercompany reconciliation, the related party schedules and the working papers done properly.

• With FINAHQ. Approved eliminations post to FINAHQ’s consolidation. One chart of accounts, one close.
• Separate deployment. Munshi ICE alone, beside SAP, Oracle, Tally or any mix of them. The journal and the working paper come out as Excel for your own consolidation. Hosted, in your cloud, or on-premise.