Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Indian audit convention rounds a fractional half-paise up on every rupee-and-paise computation — a rule every Indian CA learned in first-year articleship and carries into every audit of tax invoice tie-outs. Engineering convention, imported into most reconciliation software from the IEEE 754 banker's-rounding default, rounds a half to even. The two disagree by one paisa on every line where the exact half falls on an odd terminating digit, which for 9-percent CGST and 9-percent SGST computations is the majority of taxable values with three-decimal paise. On a thousand invoices in a month the drift is not one paisa but many rupees; on ten thousand invoices it can be a five-figure gap between the invoice book and the GSTR-1 filing. Add dual-Act TDS — where FY 2024-25 deductions still cite Income-tax Act 1961 sections and FY 2025-26 deductions cite Income-tax Act 2025 Section 393 payment codes — and reconciliation software that paraphrases either the rounding or the statute puts the year-end close at audit risk.
Enforce Decimal arithmetic with half-up rounding as the single rounding policy end-to-end. Every rate application on a taxable value produces a Decimal with three or more paise decimals; the rounding step brings it to two decimals under the half-up convention; the CGST leg and the SGST leg on an intra-state supply are computed separately at the half-rate, each rounded up on the sub-paise half, so the invoice split is visibly symmetric per the CA convention. For TDS, resolve every deduction to the correct-period statute — an invoice dated within FY 2024-25 pins to the 1961 Act section number; an invoice dated within FY 2025-26 pins to the Income-tax Act 2025 Section 393(1) schedule entry with its payment code 1001 through 1092. The payment code, not just the rate, must appear in the TDS reconciliation output because Form 26AS and the challan tie-out require the code exactly.
Rounding policy is half-up rounding on all monetary computations at two-decimal paise precision. Money type is fixed-point Decimal; floating-point money is refused at the input boundary. Tax-computation ordering is (taxable value × rate) → round to paise, applied per leg (CGST and SGST separately for intra-state; IGST as a single leg for inter-state). Dual-Act TDS resolution keys on invoice date: on or after 1 April 2025 resolves to Income-tax Act 2025 Section 393(1) with the applicable Sl. number and payment code (1001 through 1092); before 1 April 2025 resolves to Income-tax Act 1961 with the legacy section number. Section 170 rupee rounding at the return-aggregate level is a separate step applied only at the GSTR-3B summarisation, never at the invoice line.
The reconciliation output states every rupee to the paise, every paise resolved under half-up rounding, every CGST/SGST leg equal on the split as the CA convention requires, every TDS entry pinned to its correct-period statute with its correct payment code. Auditors ticking the invoice book against the GSTR-1 filing find no per-line paise drift; auditors ticking Form 26AS against the TDS reconciliation find every deduction citing its statute and payment code with no paraphrase. The rupee-and-paise expression is reproducible byte-for-byte on a re-run of the same period — the audit trail required by Rule 3(1) proviso is preserved without commentary.
An FMCG controller in Mumbai closes the March 2026 books and finds a ₹4,847 gap between the invoice book’s aggregate CGST for the month and the CGST as computed by the reconciliation tool the finance team switched to at the start of the fiscal year. The gap is not fraud, not a data problem, not a rate mismatch. It is a rounding convention gap — the invoice book, generated by the ERP, has always used half-up rounding on the paise-level CGST computation as every Indian CA expects. The new reconciliation tool defaults to banker’s rounding, the IEEE 754 default that engineers reach for reflexively. The one-paisa disagreement on each of thousands of intra-state invoices with a fractional half-paise on the 9-percent CGST computation compounded across the month into rupees, and now sits on the trial balance as an unexplained “Suspense — GST rounding” account that the statutory auditor will not sign off. This is the everyday consequence of getting paise exact decimal half-up rounding India reconciliation wrong — and it is the reason reconciliation infrastructure that intends to serve Indian finance teams has to enforce the CA convention end-to-end, not the engineering convention.
The claim in one paragraph
Every rupee reconciled through TransactIG is reconciled to the paise, every paise rounded under Decimal half-up rounding — the rule every Indian CA expects and every audit tie-out assumes. CGST and SGST legs on intra-state supplies follow the CA-ratified up-rounding convention, so the split is visibly symmetric on the tax invoice and the GSTR-1 filing agrees with the invoice book to the paise. TDS resolution is dual-Act aware: deductions attributable to FY 2024-25 cite Income-tax Act 1961 sections (194C, 194J, 194H, 194I, 194A, 194Q and so on); deductions attributable to FY 2025-26 cite Income-tax Act 2025 Section 393(1) schedule entries with payment codes 1001 through 1092. The statute follows the invoice date, not the reconciliation run date. The rounding policy and the statute pinning are not paraphrased anywhere — the output cites exactly what Form 26AS, the CGST return, and the auditor expect. The customer-visible guarantee is that the paise on the reconciliation output equal the paise on the invoice book equal the paise on the statutory filing, byte for byte.
Why this matters for the audit partner and the finance director
Every rounding decision in an Indian finance system is an accounting policy, and every accounting policy is auditable. The CA convention that a half-paise rounds up is not a personal preference — it is the convention every ICAI-trained auditor was taught in articleship, the convention printed on decades of tax invoices, and the convention that Form 3B totals reconcile to when a GST officer pulls the GSTR-1 detail and ticks the aggregate. Software that uses a different convention introduces per-line paise disagreements between the invoice book and the return filing. Those disagreements land in a rounding suspense account that no one wants to explain at the audit committee meeting.
Here is what breaks in most systems. Reconciliation software written for a general-purpose global market imports the IEEE 754 floating-point default, which is round-half-to-even — the “banker’s rounding” convention favoured in statistics because it removes systematic bias across a large sample of half-values. The Python round() builtin does this. The default rounding on float arithmetic in every mainstream language does this. Databases that store money as NUMERIC(18, 2) and let the SQL engine round the intermediate at select time can produce banker’s-rounded output without the operator even realising. When such software computes CGST at 9 percent on a taxable value that produces a paise ending on the sub-paise half, half the invoices in the month round down (because the paise digit is even), half round up (because the paise digit is odd). The aggregate over ten thousand invoices differs from the ERP-generated invoice book by rupees. The finance director sees the gap in the trial balance, the auditor asks for the reconciliation, and neither the software vendor nor the finance team can point to a single-line explanation that is not “the software rounds differently.”
The Companies Act 2013 audit-trail rule — Rule 3(1) proviso of the Companies (Accounts) Rules 2014 — requires every accounting decision to be recorded with a date-stamped, non-editable trail. Rounding is an accounting decision. Software that silently uses one convention for two years, then silently changes to another convention on a version upgrade, leaves the finance director unable to satisfy Rule 3(1) even if the outputs happen to be individually correct. The CA convention discipline exists precisely so that the rule is satisfied without commentary.
The Indian regulatory and accounting framework
Three statutory anchors matter here.
The CGST Act 2017 Section 15 governs the value of supply. Tax is computed as a percentage of the transaction value and expressed in rupees and paise on the tax invoice. Section 34 governs credit and debit notes: any adjustment to the value or the tax must apply the same rate on the adjustment amount, and the paise-level agreement between the original invoice and the adjustment note is what the department checks. Section 170 handles rupee-level rounding at the return-aggregate level — tax payable is rounded to the nearest rupee, with fifty paise or more rounding up — but Section 170 does not govern the paise-level rounding on the invoice line. That is a separate discipline enforced by the Rules and by the CA convention embedded in decades of practice.
The Income-tax Act 2025 replaces the 1961 Act with effect from tax deductions attributable to FY 2025-26 onward. Section 393(1) consolidates all TDS provisions into a single tabulated schedule. Sl. 6 payment code 1002 replaces 194C contractor deduction at 1 percent for individuals/HUF (2 percent for others); Sl. 15 payment code 1005 replaces 194J professional fees at 10 percent; Sl. 18 payment codes 1015 and 1016 replace 194H commission at 5 percent above threshold; Sl. 21 payment code 1017 replaces 194I rent on immovable property at 10 percent for land and building; Sl. 25 payment code 1009 replaces 194Q goods purchase deduction at 0.1 percent above threshold. Every payment code in the 1001-1092 range maps to a legacy section number and a rate. Reconciliation that resolves to the wrong-period statute will present a TRACES mismatch that the department will not accept — the payment code on the deductor’s challan must equal the payment code that Form 26AS attributes to the deductee.
Ind AS 8 defines an accounting policy as a specific rule or practice applied in preparing financial statements. A rounding convention is precisely such a rule. Changes between periods are either policy changes (with prospective or retrospective disclosure) or corrections of prior-period error (with restatement). Silent software-driven changes are neither, and the auditor cannot sign off unqualified without one of the two treatments being applied.
A worked example — the CGST/SGST split on a routine intra-state invoice
Illustrative — the invoice figures below are representative of the operating pattern, not any specific customer or transaction.
Consider an intra-state supply of ₹1,52,384.55 taxable value at 18 percent GST. The invoice is generated in the ERP and the tax is computed at 9 percent CGST and 9 percent SGST.
| Computation step | Value |
|---|---|
| Taxable value | ₹1,52,384.55 |
| 9% CGST — raw computation | ₹13,714.6095 |
| 9% SGST — raw computation | ₹13,714.6095 |
| CGST after half-up rounding | ₹13,714.61 |
| SGST after half-up rounding | ₹13,714.61 |
| Total tax on line | ₹27,429.22 |
| Invoice grand total | ₹1,79,813.77 |
Under the CA convention the split is visibly symmetric: both CGST and SGST equal ₹13,714.61, the up-rounded paise value, and the invoice ties to the return line for line.
Now the same invoice reconciled through software that defaults to banker’s rounding. The raw computation of ₹13,714.6095 has a digit-5 terminator. Banker’s rounding looks at the preceding digit — the “9” in the second decimal — determines whether it is even or odd (odd), and rounds the half toward the even outcome (which is up to ₹13,714.61 in this case). But now consider a different invoice: taxable value ₹1,52,375.00 at 9 percent produces ₹13,713.75. Banker’s rounding sees the “7” in the second decimal — odd — and rounds to the even ₹13,713.80. Half-up rounding takes the half up to ₹13,713.75 → ₹13,713.75 (no rounding needed; already two decimals) — actually let me correct: ₹13,713.75 is already at two paise; the interesting case is ₹13,714.605 which under banker’s rounding takes “0” (even) and rounds to ₹13,714.60, while half-up rounding takes it to ₹13,714.61. On the CGST leg the invoice book records ₹13,714.61; the reconciliation tool records ₹13,714.60; the paise gap is one on that line.
Across a thousand invoices in a month with roughly half the paise terminators falling on odd/even digits, the aggregate gap between the ERP invoice book and the reconciliation output is on the order of five to ten rupees per thousand invoices. Across a mid-sized organisation running fifty thousand intra-state invoices a month, the aggregate GST reconciliation gap is in the hundreds of rupees per month, thousands per quarter, tens of thousands over the year. That is the size of the “Suspense — GST rounding” account no auditor will sign off without a policy note under Ind AS 8.
A worked example — dual-Act TDS on the same professional invoice across the year-boundary
Consider a professional services invoice from a consulting firm for ₹5,00,000 (net of GST). If the invoice is dated 30 March 2025, the TDS event falls within FY 2024-25 and is governed by the Income-tax Act 1961 Section 194J at 10 percent. If the identical invoice is dated 5 April 2025, the TDS event falls within FY 2025-26 and is governed by the Income-tax Act 2025 Section 393(1) Sl. 15 payment code 1005 at 10 percent. The rate is 10 percent in both cases. The TDS amount is ₹50,000 in both cases. But the certificate the deductor issues, the section quoted on the challan, the payment code lodged with TRACES, and the entry in the deductee’s Form 26AS is different across the boundary.
Reconciliation software that resolves the invoice to “10 percent professional fees TDS” without pinning the section and payment code loses the ability to tie out to Form 26AS at the deductee’s PAN level. The department’s TRACES portal presents the deducted tax with the payment code the deductor filed; the deductee’s Form 26AS reflects that same payment code; a reconciliation output that says only “194J-equivalent” fails to substantiate the credit if the deductor filed under Section 393 payment code 1005. The reverse — a deductor filing under Section 393 for a March 2025 deduction — fails the challan validation at NSDL because the payment code did not exist for a FY 2024-25 attribution.
Dual-Act discipline is: resolve every TDS entry to the exact statute and payment code that applies at the invoice date, cite it exactly in the output, and refuse to paraphrase.
What this means for you at each altitude
- CFO: every rupee on the reconciliation output is defensible to the paise. The trial-balance “Suspense — GST rounding” account is empty. The Ind AS 8 accounting-policy note discloses “Half-up rounding applied end-to-end on paise-level tax computations, consistent with prior years” — one line, no restatement, no auditor question.
- Audit partner: the CGST reconciliation matches the CA convention you were trained on. Every intra-state invoice shows CGST equal to SGST on the split (symmetric on the sub-paise half); the invoice book aggregate ties to the GSTR-1 filing to the paise; the Form 3B rupee rounding under Section 170 CGST is a separate, documented step. Your team ticks and moves on.
- Integration engineer: floating-point money is not on the table. The Decimal contract is enforced at every boundary — inputs are validated to Decimal at ingress; every arithmetic step preserves paise precision; half-up rounding is applied at the two-decimal quantise, once, at the right layer. There is no place in the code path where an IEEE 754 default can smuggle a banker’s-rounded intermediate into a customer-visible output.
- Operations lead: the dual-Act TDS pin — 1961 vs 2025 — happens automatically based on the invoice date. Your team enters the invoice, the reconciliation output carries the exact section number and payment code that matches Form 26AS, and the year-boundary chaos from FY 2024-25 to FY 2025-26 does not become your problem.
The CGST/SGST split — why symmetry is not a nice-to-have
Some engineering-minded observers argue that on an intra-state invoice, banker’s rounding preserves overall accuracy across a large population — the odd rounding-down errors cancel the odd rounding-up errors, and the aggregate GST across a large book is closer to the mathematical ideal. This is true in a statistical sense and irrelevant in an audit sense. The audit is not on the aggregate accuracy of the arithmetic; the audit is on line-by-line tie-out to the invoice book, and the invoice book was generated by an ERP that in India runs the CA convention. The CGST leg and the SGST leg on the same invoice must be equal — that is the visible symmetry that a CA is trained to expect on an intra-state supply. Banker’s rounding breaks that symmetry roughly half the time (whenever the paise terminator is odd and the split value falls on the half), and the CA ticking the invoice sees CGST ₹13,714.60 alongside SGST ₹13,714.62 and stops on the discrepancy, even though the total is correct. The pattern-recognition heuristic every trained Indian auditor uses is “CGST = SGST on the split” — reconciliation that violates that heuristic burns audit time on false alarms.
The Section 170 rupee-rounding layer — a separate discipline
Section 170 of the CGST Act requires that the amount of tax, interest, penalty, refund, or any other sum payable under the Act be rounded to the nearest rupee — fifty paise or more rounds up. This is a return-aggregate-level rounding, applied at the Form 3B summarisation step where the aggregate paise-level CGST and SGST across all invoices in the month is expressed as a rupee-rounded liability. Section 170 does not govern paise-level rounding on the invoice line — Rule 46 of the CGST Rules governs invoice formatting, which requires the tax amount to be shown in rupees and paise, and the paise-level rounding on the computation is what CA convention supplies. Reconciliation infrastructure must therefore keep three rounding layers clean:
- Per-invoice-line paise-level rounding on the tax computation — half-up rounding under the CA convention, applied at the two-decimal quantise.
- Invoice-total expression in rupees and paise — sum of the paise-level rounded legs, no further rounding.
- Return-aggregate rupee rounding under Section 170 — applied only at the GSTR-3B summarisation, once, at the aggregate expression.
Software that treats these as one rounding decision — or that silently rounds at layer 1 with a different convention than the ERP-generated invoice book — produces disagreements at layer 3 that surface only when the department reconciles Form 3B totals to Form 1 invoice-level detail during a scrutiny or audit.
How TransactIG delivers this in practice
Every monetary value enters the reconciliation engine as fixed-point Decimal; floating-point money is refused at the input boundary as a category error. Every rate application produces a Decimal at raw precision and is quantised to two-decimal paise under half-up rounding, once, at the point the value is expressed. Intra-state CGST and SGST legs are computed and rounded separately at the half-rate so the split is visibly symmetric per the CA convention. TDS entries resolve to their correct-period statute automatically based on the invoice date — Income-tax Act 1961 section numbers for FY 2024-25 attributions, Income-tax Act 2025 Section 393(1) schedule entries with payment codes 1001 through 1092 for FY 2025-26. Section 170 rupee rounding is a separate step applied only at return-aggregate summarisation. The rounding convention is one accounting policy across the engine, documented, unchanged across releases without a policy note, and reproducible byte-for-byte on any re-run of the same period. This is what Why TransactIG means when it commits to paise-exact reconciliation — the phrase is not marketing; it is the CA convention, enforced.
The related product principles complete the picture. Deterministic reconciliation and audit reproducibility covers why the same inputs produce the same outputs on every run — the discipline that pairs with paise-exact rounding to make the Rule 3(1) audit trail preservable. Accounting-identity checks and money conservation covers why the reconciliation refuses to publish outputs where the paise do not balance across the identity. One engine, 24 industry presets covers how the same rounding discipline applies uniformly across every industry configuration — retail, FMCG, manufacturing, automotive, hospitality, healthcare — because the CA convention does not vary by sector.
For a broader anchor on how these principles fit together, the Why TransactIG page carries the five differentiator claims in one place. For the underlying reconciliation discipline that carries paise-exact through year-end close, the reconciliation fundamentals cluster covers the closing discipline, and the audit & assurance cluster covers the audit-partner side of the tie-out. For the commercial pillar, the reconciliation software India money page is the buyer-facing summary.
The five FAQs above address the operational questions Indian finance directors and audit partners ask most often about rounding conventions in Indian reconciliation.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →