Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Four reconciliation streams — bank, TDS, GSTR-2B input tax credit, and GSTR-1 versus GSTR-3B — hit the same three days at month end because each is anchored to a different statutory date. The compression means one stream's exception forces another stream's compromise, the ITC figure that populates GSTR-3B Table 4 is not three-way reconciled against IMS and the purchase register, and the team files GSTR-3B at 11:47pm on the twentieth under time pressure rather than under evidence. The failure surface is not a broken finance team; it is a broken cadence.
Sequence the four streams across a twenty-day operating window with a named window for each. Days 1 to 5 for bank reconciliation. Days 6 to 10 for TDS deposit and receivable reconciliation. Days 11 to 15 for GSTR-2B input tax credit matching and the at-risk queue against the Section 16(4) November 30 deadline. Days 16 to 20 for GSTR-1 versus GSTR-3B, cross-stream tolerance checks, and controller sign-off before an 11am Day 20 filing. Every stream has a preparer, an independent reviewer, and a sign-off gate that must close before the next stream begins. The escalation protocol runs on a calendar clock — Tier 1 at thirty days, Tier 2 at sixty, Tier 3 at ninety days for most items and reverse-calculated from November 30 for at-risk ITC. A Friday 4pm failure review closes the loop with the reconciliation process design register.
A one-page monthly close calendar published to the team on Day 0. Named roles for each stream — AR analyst, AP analyst, tax executive, tax manager, finance manager, controller. Standard extract cadence per portal — bank statements on Day 0, TDS payable ledger on Day 6, GSTR-2B pull on Day 12 for stability after the fourteenth-of-the-month generation, GSTR-1 versus GSTR-3B on Day 17. Escalation triggers documented per exception class, with the November 30 Section 16(4) deadline as the hard anchor for the ITC queue. Working papers filed in a single monthly folder, cross-referenced to the reconciliation process design register so every High-Priority failure mode has an owner and a detection control that fires inside a specific day of the cadence.
All four reconciliations closed by Day 20, with GSTR-3B filed on Day 20 morning rather than at 11:47pm. GSTR-3B Table 4 populated from the signed-off Day 15 GSTR-2B match; Table 6 populated from the signed-off Day 10 TDS reconciliation; Table 3.1 populated from the signed-off Day 17 GSTR-1 versus GSTR-3B check. Working papers ready for statutory audit sampling under Section 143(3)(i) and CARO 2020 Clause 3(ii)(b) evidence for the quarterly bank statement. No exception carried to next month without a written age note, an escalation owner, and an escalation-date entry on the controller's calendar. A weekly failure review that keeps the reconciliation process design register connected to the runbook exceptions.
Most Indian finance teams close the month in the last seventy-two hours. A cadence that could run cleanly across a twenty-day window compresses into a scramble on the eighteenth, nineteenth, and twentieth — bank reconciliation, TDS challan deposit, GSTR-2B pull, IMS actions, ITC match, GSTR-3B filing, all colliding at once. The result is not a broken finance team. It is a broken cadence. This guide is the day-by-day playbook for running the four reconciliation streams every Indian enterprise runs — invoice to bank, TDS against Form 26AS or Form 168, GSTR-2B input tax credit matching, and GSTR-1 versus GSTR-3B — as a synchronised sequence rather than a last-week scramble. It names the role that does each step, the portal or tool the step happens in, the exception trigger that stops the sequence, and the sign-off gate that closes it.
Why most month-ends compress
The four reconciliation streams have four different statutory anchors, and left to their own drift they arrive at month-end in the same three-day window. Bank reconciliation is anchored to the calendar month end. TDS deposit is due by the seventh of the following month. GSTR-1 is due by the eleventh. GSTR-3B is due by the twentieth. Each date is defensible in isolation. Run together without a sequence, they produce a compression where every stream is late, every stream is under-reviewed, and the finance team files GSTR-3B at 11:47pm on the twentieth with an ITC figure that has not been three-way reconciled against IMS and the purchase register.
The fix is not more hours. The fix is a sequence. Each stream has a window inside the twenty-day cycle. Each window ends with a sign-off gate. The next stream does not begin until the previous one is closed or its exceptions have a named owner and an ageing rule. Nothing in this playbook is new discipline — every Indian finance team has run some version of it — but publishing it as a sequence, with named roles and hard gates, is what turns it from a scramble into a process.
The four streams and how they interlock
The streams are not independent. Bank reconciliation feeds into TDS receivable ageing, because the bank credit is what confirms the TDS-net receipt. TDS deposit reconciliation feeds into GSTR-3B, because Table 6.2 of GSTR-3B reports the TDS collected under Section 51 as an offset to output liability. GSTR-2B input tax credit reconciliation feeds into GSTR-3B Table 4, because ITC claimed cannot exceed the GSTR-2B figure under Rule 36(4). GSTR-1 outward supply must reconcile to GSTR-3B liability under Table 3.1, because the mismatch is what triggers a DRC-01B auto-notice under Rule 88C.
The dependency graph runs bank → TDS → GST, and it runs one way. A missed bank credit that turns out to be a TDS-net customer payment forces a re-run of TDS receivable ageing. A missed IMS action that changes the GSTR-2B figure forces a re-run of the ITC match. A GSTR-1 amendment that changes the outward supply total forces a re-run of the GSTR-3B liability calculation. Every out-of-sequence discovery costs a day. The twenty-day cadence is designed to catch these discoveries in the right window so they do not cascade.
This playbook works alongside Terra Insight’s reconciliation process design method — the design layer that identifies every way each reconciliation function can fail, ranks the failures by severity, and specifies the prevention and detection controls. The design method tells you what can go wrong at each function; this playbook tells you how to sequence the functions so the failures get caught in the right window. The two are engineered as a pair: design informs the sequence, and the sequence produces the exception data that refreshes the design register.
Day 0 — the pre-close checklist
Day 0 is the last working day of the month being closed. Before the sequence starts, the following must be true.
- Bank statements downloaded. MT940 or CSV extracts from every active current account, dated to the last calendar day of the month. Formats vary: HDFC and ICICI have different narration structures; PSU banks may need branch collection.
- ERP extracts scheduled. GL trial balance, AR ageing, AP ageing, TDS receivable ledger, TDS payable ledger, GST output register, GST input register. All extracts dated Day 0, timestamped, and archived in the monthly folder.
- Vendor and customer master validated. Any new counterparty added in the month must have PAN, GSTIN, TDS section or payment code, and supply-type captured. PAN validation failures trigger Section 206AA at 20 percent and must be resolved before deposit.
- Statutory calendar confirmed. The TDS compliance calendar confirms deposit dates for the coming month. Any deviation from the standard due dates — RBI bank holidays, extension notifications — is noted.
- Prior-month rollover items reviewed. Any exception carried from the previous cycle has a named owner, an age, and a maximum-days-open rule. Anything past the rule is escalated to the controller before Day 1.
Day 0 takes half a day for a mid-market enterprise with three current accounts and one GSTIN. It takes a full day for a multi-GSTIN group with fifteen accounts across four banks. Investing that time is the difference between running the twenty-day cadence and running the seventy-two-hour scramble.
Days 1 to 5 — bank reconciliation
Owner. AR analyst runs the debits (customer receipts); AP analyst runs the credits (vendor payments and bank charges). Both report to the finance manager for review.
Day 1. Load the MT940 or CSV extract into the reconciliation tool or the working sheet. Match auto-cleared items: standing instructions, salary NACH, EMI collections, direct customer transfers with clean UTR references. Expect 60 to 75 percent of the volume to clear on Day 1 for a well-mastered ERP.
Day 2. Handle multi-invoice aggregation. A ₹34,80,000 credit against six invoices settled in a single wire from a corporate customer needs the multi-invoice aggregation pattern — pull the remittance advice from the customer’s AP portal or from an email attachment, split the credit across the invoice tags, and confirm the split totals to the paise. If no remittance advice arrives, flag the credit as “aggregation pending” and enter it in the exception queue.
Day 3. Handle TDS-net receipts. A customer paying a ₹10,00,000 invoice net of ₹1,00,000 TDS under Section 393(1)(b) will credit ₹9,00,000 to the bank. The AR analyst identifies these using the invoice with TDS pattern, tags the receivable, and pre-populates the TDS receivable ledger with the expected credit. These pre-populated entries are what the TDS window (Days 6 to 10) will match against Form 168.
Day 4. Handle platform settlements — Razorpay, PayU, Cashfree gateway payouts, and any e-commerce aggregator inbound. Each of these arrives net of commission, TDS under Section 393(1)(l) or Section 52 TCS, and platform fees. Split the settlement into gross revenue, deduction bucket, and net receipt, and reconcile against the platform’s settlement file. Aggregator settlements for restaurants, hotels, and marketplace sellers each have their own patterns — the platform settlement pattern documents the mechanics.
Day 5. Close the bank window. Every unreconciled item at the end of Day 5 is entered into the exception queue with (a) a category — aggregation pending, TDS-net awaiting Form 168 confirmation, unidentified credit, disputed debit, timing difference; (b) an age — days since the bank date; (c) an owner; and (d) an escalation rule — thirty-day escalation to finance manager, sixty-day escalation to controller, ninety-day writeoff proposal to CFO with root cause. The finance manager signs off the bank reconciliation on Day 5. This sign-off is the gate that opens the TDS window.
CARO 2020 note. Under Clause 3(ii)(b) of CARO 2020, companies with working capital limits above ₹5 crore must reconcile bank quarterly statements to books. Running the bank reconciliation on the Days 1 to 5 cadence produces the working papers CARO 2020 requires without a separate quarterly exercise — the quarterly statement filed with the lender becomes a subset of what the monthly window has already signed off.
Days 6 to 10 — TDS reconciliation
Owner. Tax executive runs the reconciliation; tax manager reviews.
Day 6. Extract the TDS payable ledger and the TDS receivable ledger from the ERP. Confirm every payment made in the month above the deduction threshold has a matching TDS entry. For the FY 2026-27 cycle onward, use the Section 393 payment code map — code 1001 for salary is Section 392, codes 1002 to 1092 for non-salary items are Section 393, and TCS is Section 394. Any FY 2025-26 residuals still carry the legacy 194 section codes, and the cross-era reconciliation article walks through the mapping rules.
Day 7. Prepare and deposit the monthly TDS challan. The 7th of the following month is the statutory deadline; running the reconciliation on Day 6 and the deposit on Day 7 leaves no margin. Some teams prefer to deposit on Day 5 and reconcile on Day 6 to build a buffer; either sequence works if the sign-off gate is enforced. The challan carries the CIN — Challan Identification Number — which becomes the primary key for the TRACES match in the next window.
Day 8. Match the deposited challan against the ERP TDS payable ledger. Any short-deduction, wrong-section, or wrong-payment-code entry surfaces here. Fix the entry in the ERP, re-run the challan if the deposit is materially wrong, and file the correction statement under the correction workflow. Do not carry a wrong deposit into the quarterly return — the correction workflow is faster than the demand-and-response cycle under Section 200A.
Day 9. Reconcile the TDS receivable ledger against the customer bank credits pre-populated on Day 3. Every TDS-net customer receipt should have a matching TDS receivable entry. The customer is expected to file its TDS return by the next quarterly cycle, but the receivable is booked in the month of receipt. This is where the quarterly Form 168 (or Form 26AS for pre-2026-27 cycles) reconciliation begins to build up — the running TDS receivable balance is what the quarterly reconciliation window in the third month of the quarter will match against the deductor’s certificate. The Form 168 article covers the certificate mechanics.
Day 10. Close the TDS window. Any TDS receivable open for more than one quarter without matching Form 168 credit enters the exception queue, categorised as (a) awaiting Form 168 posting, (b) deductor short-deducted (chase the deductor for a corrected certificate), (c) Section 206AA higher rate applied due to PAN mismatch (chase the deductor for correction), or (d) Circular 23/2017 violation — TDS deducted on GST-inclusive amount, requires refund. The tax manager signs off the TDS reconciliation on Day 10. This sign-off is the gate that opens the GST window. Terra Insight’s TDS failure modes brief documents what each of these exception classes is designed to catch and why the sign-off gate matters when the volume grows.
Quarterly emphasis. In the third month of every quarter — June, September, December, March — Days 6 to 10 also include the full Form 168 reconciliation against the TDS receivable ledger. Add half a day to the window; run the aging queue with a 180-day maximum-open rule; escalate any deductor with a repeat shortfall to the tax manager for a direct conversation with the deductor’s tax head before the correction window closes.
Days 11 to 15 — GSTR-2B input tax credit reconciliation
Owner. Indirect tax executive runs the reconciliation; tax manager reviews; controller signs off because Section 16(4) exposure sits at the top of the severity ladder.
Day 11. The GST portal generates GSTR-2B on the 14th of the following month, so Day 11 is used to complete IMS actions on the previous month’s inbound invoices. The Invoice Management System was introduced in October 2024 and changed the reconciliation workflow — every inbound invoice must be actioned (Accept, Reject, Pending) before it locks into GSTR-2B. Missing an IMS action defaults the invoice to Accept, which can silently pull a wrongly issued invoice into ITC. Day 11 is the deadline to complete IMS actions on the month just closed.
Day 12. Pull the GSTR-2B from the GST portal (generated on the 14th; pull on the 15th for full stability). Extract the purchase register from the ERP, dated to the last day of the month. Load both into the working sheet or reconciliation tool.
Day 13. Run the three-way match — purchase register vs GSTR-2B vs IMS actions. The IMS vs GSTR-2B article documents the three-way match logic. Categorise every invoice:
- In purchase register and in GSTR-2B (matched). Claim in GSTR-3B Table 4.
- In purchase register, not in GSTR-2B. Supplier has not filed GSTR-1. Move to the at-risk queue and start the supplier follow-up. The Section 16(4) clock is running.
- In GSTR-2B, not in purchase register. Ghost invoice or missed vendor invoice booking. Investigate immediately — this is a common fraud vector and a common oversight vector.
- In GSTR-2B, IMS Reject action taken. ITC not claimed (correct behaviour if the invoice was rejected for a valid reason).
- In GSTR-2B, IMS Pending. ITC deferred to next month; not claimed this cycle.
Day 14. Handle Rule 42 and Rule 43 reversals for common credit, Rule 37 reversal for 180-day non-payment to supplier, Rule 37A reversal for supplier non-filing, and Section 17(5) blocked ITC. Each of these has its own reconciliation logic and its own exception category.
Day 15. Close the GSTR-2B window. The controller signs off the ITC figure that will populate GSTR-3B Table 4. Any at-risk invoice — supplier’s GSTR-1 not filed — enters the aging queue with the November 30 Section 16(4) deadline as the escalation trigger. This is the queue that Terra Insight’s GSTR-2B ITC failure modes brief documents as the canonical high-severity failure mode above the threshold where manual detection remains economically viable. Sign-off on Day 15 fixes the ceiling for the month; the ceiling cannot be raised in the next four days without re-opening the window and re-scoring the exceptions.
Days 16 to 20 — GSTR-1 versus GSTR-3B, cross-stream, and sign-off
Owner. Indirect tax executive prepares; tax manager reviews; controller signs off before filing.
Day 16. File GSTR-1 by the 11th of the following month (statutory deadline). The Days 16 to 20 sequence assumes GSTR-1 has been filed. If your team files GSTR-1 on the 11th and runs the twenty-day cycle from Day 1 = 1st of the month, GSTR-1 is filed on Day 11. Adjust the calendar to your actual filing date; the sequence is the same, only the calendar shifts.
Day 17. Reconcile GSTR-1 outward supply against the ERP output GST register. Categorise variances: invoice reported in wrong month; export invoice misclassified; credit note timing drift; amendment window items. This is the reconciliation that prevents the DRC-01B auto-notice — DRC-01B is issued under Rule 88C when GSTR-1 declared liability exceeds GSTR-3B payment. Fix the mismatch in the GSTR-3B calculation before filing.
Day 18. Assemble the GSTR-3B — Table 3.1 outward liability from GSTR-1; Table 4 ITC from the Day 15 GSTR-2B match; Table 6 payment reconciliation including TDS under Section 51 from the Day 10 TDS window; Table 6.2 TCS credits. Every table pulls from a signed-off working paper from the earlier windows. Nothing in GSTR-3B is calculated for the first time on Day 18 — it is only assembled.
Day 19. Independent review. The tax manager reviews the GSTR-3B assembly against the working papers. Any calculation that cannot be traced to a signed-off working paper is escalated to the controller. The three-way GSTR-9C mismatch trap is what a misassembled GSTR-3B produces at year-end; Day 19 is where the mismatch is caught before it becomes a year-end forensic exercise.
Day 20. File GSTR-3B by 11am. Not by 11:47pm. The four-hour buffer is what allows a portal issue, a payment lag, or a last-minute correction to be handled without missing the statutory deadline. The controller signs off the filing on Day 20.
Cross-stream reconciliation. Days 18 to 19 also cover the cross-stream check: bank reconciliation total credits minus TDS receivable movement should match ERP revenue for the month within a defined tolerance; ERP output GST should tie to GSTR-1 declared liability within a defined tolerance; GSTR-3B ITC claimed should tie to the purchase register within the GSTR-2B ceiling. Three tolerance checks, three sign-offs, three defensible working papers.
The escalation protocol
Every exception queue in every window has three escalation tiers.
- Tier 1 — 30 days. Escalated to the finance manager. Standard follow-up letter goes out. Working paper updated with the escalation date.
- Tier 2 — 60 days. Escalated to the controller. Second follow-up letter, and the counterparty’s key account owner — sales for AR items, procurement for AP items — is looped in.
- Tier 3 — 90 days for most items; reverse-calculated from the November 30 Section 16(4) deadline for ITC-at-risk items. Escalated to the CFO. Writeoff proposal or provision entry prepared. For a March invoice sitting in the at-risk ITC queue, Tier 3 fires around September so there is a two-month window to recover before the permanent loss triggers on November 30. For non-ITC items, the fixed 90-day counter runs from the date the exception entered the queue.
The escalation dates are calendar-based, not reconciliation-cycle-based. An item that entered the queue on the 5th of April escalates on the 5th of May, the 5th of June, the 5th of July — regardless of which reconciliation cycle is running. The controller’s inbox on the 5th of each month carries every 30-day and 60-day escalation across every queue. This is the single control that most reliably prevents the permanent-loss silent-drift pattern.
The weekly failure review
The twenty-day cycle produces an exception queue. The queue is a stream of raw data. Turning the data into process improvement requires a weekly review.
Every Friday at 4pm, the tax manager and the finance manager review the week’s new exception entries and the escalations that fired. The review has three questions.
- What new failure mode does this expose? If the exception is a class the reconciliation process design register has not documented, it enters the register as a new row and gets scored on Severity, Occurrence, and Detection.
- What existing control failed? Every High-Priority row in the register has a documented detection control. If an exception surfaced without the detection control firing, the control has failed and needs to be re-scored on Detection or replaced. Cross-check the stream-specific briefs — the GSTR-2B failure modes brief, the TDS failure modes brief, and the control plan template — to see whether a documented mode was missed or whether this is a genuinely new mode.
- What prevention change would stop the recurrence? If the failure mode has surfaced more than once in three months, the prevention control needs to change — ERP field enforcement, template redesign, cutoff calendar amendment, training refresh.
The weekly review is thirty minutes if the cycle is clean. It is two hours if the cycle produced ten new exception classes. Either way, the review is the loop that keeps the design register and the operational cadence connected — the design informs the runbook; the runbook exceptions update the design. Teams that want a structured starting point can use Terra Insight’s reconciliation process design worksheet as the source register for the weekly review, filling in one row per exception class as it surfaces.
When you fall behind — the catch-up playbook
Some months, the cycle breaks. A senior analyst quits without a handover. The ERP upgrade holds up the extracts for a week. The controller was on leave for the IMS deadline. The result is a backlog, and backlogs in Indian reconciliation compound faster than most finance teams expect. A missed IMS action becomes a locked-in wrong ITC figure. A missed vendor GSTR-1 follow-up in March becomes a permanent loss in November. A missed TDS correction becomes a Section 200A demand in the next quarter.
The catch-up rules are simple.
- Backlog under 30 days. Recoverable within the current cycle by doubling the extract cadence and pulling a second reviewer onto the queue. No structural change required. Freeze the discretionary work; run a compressed version of the twenty-day cadence over ten calendar days; catch up during the current month.
- Backlog 30 to 90 days. Recoverable through a dedicated 4 to 6 week catch-up sprint. Freeze new discretionary work; assign one senior and one analyst full-time to the sprint; run the twenty-day cadence in compressed form for each backlogged month, oldest month first for GSTR-2B (Section 16(4) is running), current month first for GSTR-1 versus GSTR-3B (DRC-01B is the near-term risk). The 90-day GSTR-2B catch-up plan frames the ITC-side of a mid-range backlog.
- Backlog over 90 days. Structural intervention required. This is where the finance team must either bring in an external CA firm for the catch-up or install a reconciliation infrastructure layer to handle the volume the catch-up demands. Continuing the manual cycle from a 90-day backlog is what produces the notice cascade — DRC-01B for one month, Section 200A for another, DRC-01C for a third — each triggering its own response timeline and multiplying the compression.
The point is not to prevent backlogs — every finance team has months where the cycle breaks. The point is to have a documented response the moment the backlog is detected, so the catch-up runs as a planned exercise rather than a crisis.
When manual process outgrows itself
The playbook is designed for a finance team that runs its own reconciliation manually or with light Excel automation. It works up to a specific set of thresholds. Above those thresholds, the manual cadence cannot be sustained without either burning out the team or accepting the permanent-loss failure modes Terra Insight’s reconciliation process design framework documents.
The three thresholds where manual runbooks outgrow themselves are:
- 200-plus vendors under GSTR-2B. The IMS action cadence, the vendor-side GSTR-1 follow-up queue, and the at-risk aging queue against the November 30 deadline consume disproportionate analyst time. The at-risk queue in particular requires daily refresh, which is not compatible with a Day 11 to Day 15 window. This is where GST reconciliation software treats the at-risk ITC queue as a first-class output rather than a queue the analyst has to hand-maintain.
- Multi-GSTIN, multi-entity groups. The cross-GSTIN reconciliation and the intercompany elimination produce a coordination overhead that compresses the twenty-day cycle into a fifteen-day cycle for the group controller. A continuously automated aging queue with escalation triggers is what closes the compression back down to twenty days for the group without adding heads.
- Aggregator-heavy revenue models. Restaurants running Zomato, Swiggy, Magicpin, and Dunzo; hotels running MakeMyTrip, Goibibo, Booking.com; e-commerce sellers running Amazon, Flipkart, Ajio, Myntra. Every additional platform adds a settlement file with its own format, its own commission structure, its own TCS treatment, and its own reconciliation window. Above four platforms, the platform-settlement window bleeds into every other window.
The response is not to give up the playbook — the discipline is what makes reconciliation infrastructure like TransactIG defensible in the first place. The response is to move the detection layer from the analyst’s eye to a continuously refreshed system, freeing the twenty-day cycle from the failure modes it was quietly absorbing.
Where this fits
- TransactIG — reconciliation infrastructure
- Reconciliation software for India — pillar guide
- GST reconciliation software
- TDS reconciliation software
Related reading
- Reconciliation process design — the design layer above this playbook
- GSTR-2B ITC reconciliation failure modes — what the Day 15 sign-off is designed to catch
- TDS reconciliation failure modes — what the Day 10 sign-off is designed to catch
- Reconciliation control plan template
- Section 16(4) ITC time bar — the anchor for the Tier 3 escalation clock
- Form 168 — the new TDS statement
- Cross-era TDS reconciliation
- Invoice Management System reconciliation
- CARO 2020 bank reconciliation audit
- TDS compliance calendar
- Reconciliation process design worksheet
Frequently Asked Questions
What if my team’s month-end deadlines are different from this twenty-day cadence?
The absolute calendar shifts; the sequence does not. If your GSTR-3B is filed on the twentieth and the twenty-day cadence starts on Day 1 = 1st of the following month, GSTR-1 is filed on Day 11 (the 11th) and the sequence flows from there. If your team files monthly rather than under QRMP, the same sequence applies. If your team is on QRMP quarterly GSTR-3B, the ITC reconciliation still runs monthly against GSTR-2B; only the filing is quarterly. The four windows and their sign-off gates are the invariant — bank first, TDS next, GSTR-2B input tax credit third, GSTR-1 versus GSTR-3B and cross-stream last. The rest is calendar arithmetic.
How does this playbook relate to the reconciliation process design framework?
The reconciliation process design framework is the design layer. It identifies every way each function can fail, rates the failures on Severity, Occurrence, and Detection, and specifies the prevention and detection controls. This playbook is the operational layer. It sequences the functions across the calendar so the controls actually get run in the right window. A team that runs the playbook without a process design register is running a sequence without knowing what failures each step is supposed to catch. A team that runs the process design register without a playbook has a well-designed control plan and no working cadence. Both are needed. Terra Insight’s reconciliation process design pillar documents the design method that sits above this operational cadence, and the GSTR-2B failure modes brief shows what the Day 15 window is designed to catch.
Our finance team is three people including me — can we run this?
Yes, with role compression. The AR analyst and the AP analyst become one analyst. The tax executive and the indirect tax executive become one tax lead. The reviewer role rotates weekly between the controller and one of the analysts. The sign-off gates still hold — no self-sign-off, always an independent second look. The twenty-day cadence still works; the risk is that the exception queue backs up faster because there are fewer eyes on it. Run the weekly failure review religiously and the small team can hold the cadence indefinitely. Above two hundred vendors under GSTR-2B, or above four aggregator platforms on the revenue side, the compression stops holding and the detection layer needs to move off the analyst’s screen.
Where do MSME 43B(h) checks fit into the cycle?
The MSME 45-day payment tracker runs continuously against the AP ageing. Days 6 to 10 (the TDS window) is a natural checkpoint because the AP payables run is the same data. Extract the MSME vendor list on Day 6, cross-reference invoices approaching 45 days, and either release payment before the deadline or provide against the Section 43B(h) disallowance. Do not delay MSME tracking to year-end — the Finance Act 2023 rule makes the disallowance permanent for the year of non-payment, and a March 25 discovery is too late to release the payment inside the window that keeps the deduction alive.
Should I file GSTR-3B on Day 20 morning or overnight on Day 19?
Morning of Day 20 by 11am. Overnight filing has one advantage — no portal traffic — and three disadvantages: no time to correct a portal-side error; no time to react to a challan-side ITC ledger issue; and a working paper that was signed off before the last exception check. The four-hour buffer between Day 19 independent review and Day 20 morning filing is what separates a defensible cadence from a fingers-crossed cadence. It is also the buffer that a real portal glitch — a session timeout on the ITC ledger, a stale cache on the payment challan — needs to be diagnosed and worked around without breaching the statutory deadline.
What happens on Day 21?
Day 21 is the start of the next monthly cycle for a portion of the team. The AR and AP analysts pull the next month’s bank statements and start Day 1. The tax executive files the previous month’s TDS return by the 31st (quarterly filing) or handles the next month’s TDS deposit by the 7th. The Friday failure review on the week containing Day 21 focuses on any exception from the cycle just closed and updates the reconciliation process design register with any new failure mode surfaced. The cadence is continuous; the twenty-day windows overlap by one month across the team, and Day 21 is where the overlap becomes visible on the roster.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
- ▸ Section 393, Income-tax Act 2025 — Deduction of tax at source on payments other than salary. From April 1, 2026, all non-salary TDS deductions move from the Section 194 series to Section 393 with payment codes 1001 to 1092. The cross-era mapping window is what the twenty-day playbook's TDS window (Days 6 to 10) resolves at monthly cadence; the residual mismatch is what the quarterly Form 168 reconciliation catches. Any payment above the deduction threshold must carry the correct payment code before the challan is deposited on Day 7 to avoid a Section 200A demand under the next quarterly processing cycle.
- ▸ Section 16(4), Central Goods and Services Tax Act 2017 — Time limit for availing input tax credit. A registered person cannot claim ITC in respect of any invoice or debit note for supply of goods or services after the thirtieth day of November following the end of the financial year to which such invoice pertains, or furnishing of the relevant annual return, whichever is earlier. Where the supplier's GSTR-1 is filed after this cut-off and no book-side accrual has been made, the ITC is permanently lost. This is the anchor that turns the Day 15 controller sign-off into a Severity 10 gate — every at-risk invoice must be tracked against the November 30 deadline, and the Tier 3 escalation date is calculated backward from that deadline rather than from a fixed ninety-day counter.
- ▸ Rule 36(4), Central Goods and Services Tax Rules 2017 — Input tax credit availed by a registered person in respect of invoices or debit notes the details of which have not been furnished by the suppliers under Section 37 shall not exceed the amount of input tax credit available in respect of invoices or debit notes the details of which have been furnished by the suppliers under Section 37 in FORM GSTR-1 or IFF. The GSTR-2B figure is therefore a hard ceiling on the ITC that can be claimed in GSTR-3B Table 4. The Day 15 sign-off is where the ceiling is fixed for the month, and Day 18 assembles GSTR-3B Table 4 from that signed-off figure with no recalculation permitted.
- ▸ Rule 88C, Central Goods and Services Tax Rules 2017 — DRC-01B intimation — Where the tax payable by a registered person in accordance with the statement of outward supplies furnished by him in FORM GSTR-1 for a tax period exceeds the tax paid by such person in the return furnished for the same period in FORM GSTR-3B by such amount as may be prescribed, the system shall issue an intimation in FORM GST DRC-01B, and the registered person shall reply within seven days. Days 16 to 19 of the twenty-day playbook exist to prevent this intimation from firing — the GSTR-1 versus GSTR-3B reconciliation on Day 17 catches the mismatch before the portal auto-generates the notice.
- ▸ Companies (Auditor's Report) Order 2020, Clause 3(ii)(b) — The auditor is required to report on whether during any point of time during the year the company has been sanctioned working capital limits in excess of five crore rupees, in aggregate, from banks or financial institutions on the basis of security of current assets, and whether the quarterly returns or statements filed by the company with such banks or financial institutions are in agreement with the books of account. Running the Days 1 to 5 bank window on the monthly cadence produces the reconciled working papers CARO 2020 requires — the quarterly statement filed with the lender is a subset of what the monthly window has already signed off, and the auditor's evidence base is built during the year rather than reconstructed at year-end.