GSTR-2B reconciliation in SAP — what's automated, and what still needs a human

SAP's own documentation describes a GST inward-reconciliation module that does more than pull a number — it runs automatic invoice-level matching and computes eligible/ineligible ITC. But two things are easy to miss if you're evaluating this from the outside — what the matching engine still hands back to a person, and which SAP product this documentation is actually describing.

Two SAP products, one confusing name

Before anything else: SAP's own published guide for its GST inward-reconciliation screens — the one with GSTR-2B, GSTR-2A and IMS tabs described below — is titled "Digital Compliance Service for India", running on what SAP calls the Neo environment. SAP's documentation states plainly that this service "will no longer be available as of December 31, 2027", and that new GST reporting capability is moving to SAP Document & Reporting Compliance (DRC) for SAP S/4HANA Cloud and SAP S/4HANA, with migration guidance in SAP Note 3513669. (SAP's guide is dated 12 June 2025; treat this as the position as of August 2026.)

What SAP auto-pulls

Per SAP's documentation, the reconciliation screen (the "GSTR2" app) offers a dedicated pull option for each of the three GSTN-side sources it reconciles against, each fetched by Tax Payer GSTIN and a period filter:

Worth being precise about what GSTR-2A is for here: it's an early-warning view, not an eligibility source. Under Section 16(2)(aa) of the CGST Act, credit requires the invoice to be furnished by the supplier and communicated to you in GSTR-2B — reconcile the claim to 2B, not 2A.

The GSTR2B tab documentation states the statement "remains constant for a period." That's SAP's own characterization, not a claim we're repeating as settled law — GSTR-2B is a draft that can still change on IMS action after the 14th, and it stabilises only when GSTR-3B is filed. Whatever the pull returns is a snapshot of the moment you pulled it, not a number guaranteed to hold until you file.

SAP does do invoice-level matching — this is the part worth knowing

If you've been told SAP "just pulls the 2B number" and leaves matching entirely to a spreadsheet, SAP's own documentation doesn't support that. The Reconciliation screen classifies every reconcilable inward invoice into one of five named types, with named subtypes for anything short of a clean match (a separate Other Sections tab handles non-reconcilable invoice types such as RCM and nil-rated):

The tolerance values that decide where an invoice lands in this table are themselves configurable — SAP's documentation points to a "Recon Settings" view showing the Action and Tolerance values a Tax Administrator has set in a separate Master Data and Configuration app. Matching is automatic; the thresholds it matches against are a setup decision someone made, and worth checking rather than assuming.

What SAP computes for you: eligible and ineligible ITC

SAP's GSTR-3B documentation ("Section 4 (Eligible ITC) Details") describes a computed ITC figure, not just a pulled one: "Eligible Input Tax Credit (ITC) is calculated by deducting ITC Reversed from ITC Available", bifurcated across IGST, CGST, SGST/UTGST and cess, alongside a separate Ineligible ITC figure. That's GSTR-3B Table-4 arithmetic, not a statutory eligibility test — the eligible/ineligible flag itself is inherited from your purchase register and from GSTR-2B's own Table 3 (ITC Available) / Table 4 (ITC Not Available) split. Blocked credits under Section 17(5) and apportionment under Rule 42/43 remain your determination, not SAP's. So the SAP-side output isn't only "here's your 2B" — it's a computed eligible/ineligible split per return, at the return-period boundary: it tells you the eligible amount for the GSTIN and period you selected, not which specific invoices are driving a shortfall against what you'd expected to claim, or which ones are trending toward a reversal — that's a separate reconciliation question, covered in the Input Tax Credit pillar.

Where the automation hands off to a person

The step SAP calls IMS Save is the clearest documented evidence that matching isn't the same as filing-ready. Per SAP's procedure:

1. Every invoice carries an IMS action — Accepted, Rejected or Pending — that someone has to set (directly, or via a configured default-action rule) before it can move. On the GSTN side the default runs the other way: a record left untouched in IMS is deemed accepted into your GSTR-2B (GSTN IMS advisory; Section 38 of the CGST Act, which delegates the form and manner to Rule 60(7)). Inaction is a decision — SAP's configured default-action rule is the one actually making it.
2. Actions marked Ready to Upload then have to be explicitly selected and sent with an Upload to GSTN action — the system tracks the round trip through statuses like Sent to GSTN, In-process, Accepted by GSTN, and Accepted with errors.
3. Only after that sync succeeds does someone choose Compute GSTR2B to regenerate the statement — SAP's note is explicit that a successful GSTR2B generation then auto-triggers the next pull, but the compute step itself is not automatic.

None of that is a criticism of the tool — a rules-engine deciding whether a genuinely mismatched invoice should be accepted or rejected would be worse, not better. It's the practical reality: automatic matching narrows a purchase register down to the invoices that need a decision. It doesn't make the decision.

Vendor-level visibility: a report, not a live chase

SAP's documentation does include a Supplier Compliance Report — filtered by Taxpayer GSTIN, Counterparty PAN, Financial Year and GSTR-3B compliance — that surfaces a supplier's GSTR-1 and GSTR-3B filing compliance and the aging of that compliance. The underlying filing-status data does refresh on a schedule — SAP's documentation lists a Taxpayer Filing Status job running on the 23rd and 26th of every month, no configuration required. That's genuinely useful, vendor-level information kept current in the background.

What isn't automatic is the chase. Emailing a counterparty about a Partial Match, Probable Match or Missing-in-GSTN invoice is a separate, manual Create Notifications action, and it only reaches anyone if the taxpayer has pre-maintained an email list against each GSTIN in advance. The data refreshes on its own; someone still has to open the report, read it, and decide whom to chase — a problem that shows up the same way whatever ERP sits underneath.

How this compares to a purpose-built reconciliation layer

Put together, SAP's own documentation describes a genuinely capable pipeline, and most of it runs on a schedule with no additional configuration required once the GSTIN is set up for GSTR2: a GSTR-2B pull on the 14th–15th, a reconciliation run against five named match categories daily, and a taxpayer-filing-status refresh on the 23rd and 26th. What stays manual is the judgment and the follow-through — a decision on every Partial and Probable Match, per invoice or as a blanket default-action rule someone has to own and keep current, an explicit Upload-to-GSTN and Compute-GSTR2B round trip before the next GSTR-2B reflects those decisions, and a Create Notifications action that only reaches a vendor if someone runs it against a pre-maintained email list. For a team with a Purchase Register the size SAP is built for, that judgment layer is painful to do manually every filing cycle, month after month, invoice by invoice.

Recoup doesn't replace SAP's export or its GSTR-2B pull — it sits at that second layer, reconciling continuously from the same underlying registers, flagging the exact invoices behind a gap, and naming the specific vendor whose non-filing is blocking your credit. SAP already names the mismatch — Invoice Number Mismatch, POS/CP GSTIN Mismatch. Recoup is built to carry that from a field-level label to a resolution: which invoice, which vendor, which call, before the return is due.

Related guides