Schedule III and the Management P&L: One Ledger, Two Views

Every Indian company that reports under the Companies Act produces its financial statements in the Schedule III format — Division I for companies following Accounting Standards, Division II for those under Ind AS. And nearly every one of those companies also runs some form of management P&L, because the statutory statements were never designed to run a business. The two documents describe the same period, draw on the same ledger, and are read by entirely different audiences for entirely different reasons.

The trouble starts when a business treats them as two separate exercises. They aren’t. They are two views of one ledger, and the thing that connects a ledger to a view is a mapping: a decision, for every account, about where it belongs in that presentation. Get the mapping discipline right and both views stay consistent, traceable and cheap to produce. Get it wrong and you have two documents that quietly disagree with each other — and with the books underneath them.

What Schedule III fixes, and what it doesn’t

Schedule III is prescriptive by design. It fixes the face of the balance sheet and the statement of profit and loss — the line items, their order, their names. It fixes the note structure that sits behind each face item. It requires assets and liabilities to be classified as current or non-current on defined criteria. And it demands specific disclosure buckets that exist nowhere in a typical chart of accounts: trade payables split by dues to micro and small enterprises versus others, ageing schedules, related-party balances shown separately, and so on.

That prescription is the point. A reader of statutory accounts — a lender, a regulator, an auditor, a shareholder — should be able to pick up any company’s statements and know exactly where to look. Comparability across companies is the whole value of the format.

But prescription is also the limitation. Schedule III will tell a reader what the company’s total employee benefit expense was. It will not say which business line incurred it, whether it is trending up faster than revenue, or what contribution each segment made after its direct costs. It has no concept of a cost centre, a branch, or a product line. It is a photograph taken from a fixed position, and it is deliberately the same photograph for every company.

What the management P&L needs instead

Management reporting starts from the opposite premise: the format should fit the business, not the statute. A useful management pack cuts the same ledger by segment and cost centre, separates direct costs from overheads to show contribution, presents twelve months of trend rather than one comparative column, and groups expenses the way the leadership actually thinks about them — not the way paragraph 5 of a schedule requires. Presentation conventions differ too: a board in India reads the pack in lakhs and crores against an April–March year, with variance columns the statutory format has no room for.

So the same ledger account can, quite correctly, live in different places in the two views. A freight expense might sit inside “Other expenses” on the Schedule III face, disclosed in a note — and sit inside direct costs above the contribution line in the management P&L, allocated to the segment whose goods were shipped. Neither placement is wrong. They are answers to different questions.

The mapping is the product

This is the discipline that separates businesses whose two views reconcile from businesses whose two views merely coexist: every ledger account needs a home in both views, and each of those homes is a decision.

Three properties make a mapping trustworthy:

It is confirmed by a human. Where an account belongs — is this deposit current or non-current, is this expense direct or overhead, does this payable belong in the MSME bucket — is a judgement call, often one requiring knowledge no system has, such as the counterparty’s registration status or the contractual maturity of a deposit. A tool can suggest; only a person who knows the facts should confirm. This is precisely the kind of question on which a company’s own accountants and auditors must exercise professional judgement, and nothing here should be read as advice on how any particular account ought to be classified.

It is versioned. When a mapping changes — an expense reclassified, a grouping restructured — that change should be recorded: what moved, when, and on whose decision. A mapping that mutates invisibly makes every prior period silently incomparable.

It is consistent period to period. The same account should land in the same place every month unless someone deliberately decides otherwise. Consistency is what makes a trend mean something; a “trend” across a drifting mapping is a chart of classification changes wearing the costume of a business trend.

The classic traps

The places mappings go wrong are well known to anyone who has reviewed a draft set of accounts:

Current versus non-current calls. The classification depends on facts — maturity dates, rollover intentions, covenant status — that change between periods. A loan that was correctly non-current last year may be current this year, and a mapping frozen at last year’s answer will misstate the balance sheet while every total still adds up.

Signs and contra accounts. Accumulated depreciation, provisions netted against receivables, discounts sitting as negative revenue — accounts that carry the opposite sign to their neighbours are where a mechanical mapping produces confident nonsense. Net an account that should be shown gross, or gross one that should be netted, and both views inherit the error.

Material unclassified accounts. New accounts are created in the ledger all year — a new bank account, a new expense head, a new inter-company balance. Every one of them arrives unmapped. If the reporting process has no step that surfaces unmapped balances, they fall into a residual line or, worse, out of the statements entirely. An unclassified account holding ₹18,00,000 is not a housekeeping item; it is a misstatement waiting for a signature.

Groupings that drift. This period “software subscriptions” sits in administrative expenses; last period someone put it under communication costs. Each choice was defensible. Together they make the comparison meaningless, and nobody flagged the move because nobody could see it.

Why the Excel version breaks

Most businesses maintain this mapping the only way they can: a tab in a workbook, with account codes down one side and SUMIF or lookup formulas pulling trial-balance figures into the Schedule III faces and the management pack. It works — right up until it doesn’t, and the failure modes are structural rather than careless.

New accounts arrive unmapped, and a lookup that finds no match returns zero or an error that someone patches at eleven at night. Formulas rot: a row inserted in the trial balance shifts a range, a renamed sheet breaks a link, and the totals still look plausible because a broken formula rarely announces itself. The mapping’s history lives nowhere — the file is simply overwritten each period, so no one can say when a grouping changed or why. And the whole construction typically lives in one person’s head, which means the two views stay reconciled exactly as long as that person keeps doing it the same way.

None of this is a criticism of the people involved. It is a criticism of asking a spreadsheet to be a controlled, versioned, two-view classification system, which is not what a spreadsheet is.

What good looks like

A sound process has a recognisable shape, whatever tool produces it:

• Suggestions, never auto-applied. New and changed accounts get a proposed home in each view — based on name, group, or precedent — but nothing enters either presentation until a person confirms it.
• Unclassified balances that warn before export. The process should refuse to let a material unmapped balance slip silently into a residual line. The warning must arrive before the workbook goes out, not after a reviewer finds the hole.
• One mapping, one linked output. The Schedule III faces should trace to their notes, the notes should trace to the ledger accounts behind them, and the management pack should reconcile to the same trial balance — because all of it descends from a single confirmed mapping rather than parallel ones maintained by hand.

When those three hold, the statutory statements and the management pack stop being two documents that happen to agree and become what they always should have been: two views of one set of books.

What to expect with Datavrn

Datavrn is being built around exactly this discipline. One mapped ledger drives both views: the management pack with its segments, cost centres and contribution lines, and a linked Schedule III Excel workbook — Division I or Division II — where the faces trace to the notes and the notes trace back to the ledger. Mappings are suggested, never auto-applied; unclassified balances are visible and warn before anything exports; and the mapping itself is versioned, so period-to-period consistency is something you can demonstrate rather than assert. The judgement about where an account belongs stays with the professionals responsible for it. The machinery that carries that judgement into two consistent presentations is what the software is for.

Datavrn is being built for finance teams that produce management reporting. Request early access to hear when we’re ready.