Under Section 16(2)(aa), input tax credit exists only when the invoice appears in your GSTR-2B - and with IMS live and GSTR-3B's ITC table hard-locking to 2B data, there is no manual override left. Finnoto reconciles books ↔ 2B ↔ IMS continuously, and holds cash until credit is safe.
Illustrative product behaviour - values shown are examples.
The rules tightened: Rule 36(4) tolerance is zero, IMS actions are live on the portal, and GSTR-3B's Table 4A is hard-locking to 2B. Whatever isn't in 2B, you fund from working capital.
If a vendor doesn't file GSTR-1 - or files late, or fat-fingers your GSTIN - the invoice never reaches your 2B. That ITC is blocked, and the GST you already paid the vendor sits stranded.
2B generates on the 14th; untouched IMS invoices are deemed accepted. Excel-based recon once a quarter can't keep pace with a portal that moves monthly and locks 3B automatically.
Wrongly availed and utilised ITC attracts 18% interest, DRC-03 reversals and departmental scrutiny. Claiming from books instead of 2B is now a direct audit flag.
Finnoto keeps it in the ITC-at-risk ledger, keeps chasing the vendor on an escalation cadence, and - if you enable the rule - holds the GST portion of that vendor's payment until the invoice reflects. You decide vendor-by-vendor how strict to be.
Yes. Recommended IMS actions come from the match result - matched invoices are accepted, unknown or wrong invoices flagged for rejection, and disputed ones kept pending - before 2B generation on the 14th.
Recon tools produce a mismatch report. Finnoto is your payables layer, so the same mismatch drives vendor communication, tickets, payment holds and the ERP posting - the loop actually closes.
See your books ↔ 2B ↔ IMS position, live, with every rupee of at-risk ITC owned by someone.
Talk to us