The Invoice Management System went live on the GST portal from 1 October, and it changed the shape of input tax credit reconciliation from a reporting exercise into a workflow. Every outward supply your suppliers report in GSTR-1, IFF or GSTR-1A now appears on your IMS dashboard for you to act on. Inward reverse charge supplies and transactions ineligible for input tax credit bypass IMS entirely and flow straight to GSTR-3B.
There are three actions and they behave differently. Accepting a record puts it into the ITC Available section of your GSTR-2B. Rejecting it puts it into ITC Rejected, and the credit does not auto-populate into GSTR-3B. Marking it pending excludes it from the current GSTR-2B while keeping it in IMS for a later decision, which is the right treatment for an invoice you are still querying with the supplier.
The rule that matters most for software design is the default. At the point GSTR-2B is generated, any record with no action taken is treated as deemed accepted. Inaction is not neutral — it is acceptance. That inverts the risk for any business with volume: previously an unreviewed invoice was simply an unreviewed invoice, and now it is an accepted one whose credit you have claimed. A queue that nobody worked through used to be untidy; now it is a filing position.
The calendar is fixed and tight. Draft GSTR-2B becomes available on the 14th of the following month. You can continue to act after that and recompute, but only until GSTR-3B is filed for the same period, after which the window closes. That gives a finance team a defined and short review period every month, which is precisely the kind of recurring deadline that software should be managing rather than a person with a reminder.
Not everything can be deferred. Original credit notes, upward amendments to credit notes, and certain downward amendments cannot be marked pending, so they must be accepted or rejected in the period they appear. Any system you build needs to encode that distinction rather than offering pending universally, because the portal will reject the action and the user will not know why.
For anyone building accounting, ERP or reconciliation software, the practical design follows directly. Pull the IMS records, match them against purchase entries automatically, and present only the exceptions to a human — matched invoices accepted in bulk, mismatches surfaced with the difference highlighted, and anything unmatched flagged. Show the count of unactioned records with days remaining before the 14th, prominently. And record who took each action and when, because the deemed-accepted rule means somebody will eventually need to explain a credit that nobody consciously claimed.
