DEV Community

Tax Garden
Tax Garden

Posted on

Structural misclassification problem when bank statements drive accrual books , engineering fix with two-pass import

Most Indian SME bookkeeping workflows work backward: import bank statement, code transactions, reconcile. The bank statement becomes the de facto source of truth.

This creates a systematic misclassification problem that no amount of automation fixes.

THE ROOT ISSUE Bank statements record cash flows, not accrual events. A GST payment on June 5 for May's GSTR-3B liability gets coded as an expense in June. Under accrual accounting, it should be a settlement of a GST liability recorded in May. When books are built from bank statements, every month's GST payment is mis-dated, and the balance sheet liability account never zeroes correctly.

HOW THIS AFFECTS GSTR-2B RECONCILIATION Automated reconciliation tools that use GSTN APIs try to match purchase invoices against ITC claims. If expense recognition is cash-based but ITC claims are invoice-based, the reconciliation always shows unexplained mismatches , and the tool never catches the structural error.

THE ENGINEERING FIX Build a two-pass import:

Pass 1 , identify every transaction with a GST implication (look for known payees: "GSTN", "GST Portal", vendor names with GSTIN in description)
Pass 2 , reclassify those as liability settlements, not expenses. Backdate to the period they relate to.
The full taxonomy of misclassification types and primary source citations: Tax Garden's bank statement misclassification guide.

Top comments (0)