Every downstream number depends on where each ledger lands. Ledger Mapping is where the auditor confirms, overrides or excludes the system's proposed Schedule III bucket and statutory-applicability tags (PF, ESI, PT) for every material ledger. The engine only ever suggests — it never confirms — so whatever the auditor stamps is the truth every working paper and Schedule III aggregation reads. TDS, TCS and GST need no ledger tag at all: their verification papers read the tax leg, amount and direction structurally from the vouchers themselves.
Two paths to the same audit conclusion. One leaves traces; the other doesn't.
After the ERP data ingests, Tier 1 deterministic rules (Tally group + name + standard-group matching) resolve the large majority instantly. Ledgers Tier 1 can't settle go to Tier 2 — an LLM reads a sample of voucher narrations and proposes a value with its reason — and Tier 3 checks how auditors on other entities mapped similar ledgers. Every suggestion arrives with its stated reason.
The worksheet's stat strip separates auto-mapped ledgers (no attention needed) from rows genuinely asking for judgment. Open a flagged row to see the suggestion, its reason and a confidence badge — accept, override or mark exempt. Bulk actions cover the rest, including an accept-all for high-confidence suggestions that shows exactly how many rows it will touch before committing.
Mappings are stored per ledger and financial year, and Copy from prior FY carries confirmed mappings forward. Next year's audit opens with the same ledgers already mapped; the auditor reviews only what changed. Re-suggest re-runs the engine after a re-sync or materiality change.
Maps every ledger to its Schedule III line — a combined Balance Sheet + P&L bucket view, the default tab on load. Every ledger must land on a line (there is no exempt on this tab), and whatever you stamp is what the statements aggregate.
Lean statutory-applicability dimensions for payroll-relevant ledgers only — a ledger with no row is simply out of scope. Tag once; the PF/ESI working paper reads the tags for its dues and deposit testing.
TDS, TCS and GST classification used to live here — it was retired deliberately. The verification papers now derive the tax leg, amount and direction structurally from the vouchers themselves, so there is no ledger-level tag to go stale and no mapping debt to maintain.
One row per ledger and dimension records the status — suggested, confirmed, overridden or excluded — with the suggestion source and the auditor identity once acted on. Downstream working papers and the Schedule III aggregation read this table; the auditor's stamp always overrides whatever the engine proposed.
