GST Glossary

It is the portal-side source SaralKar compares against your purchase register to find mismatches before filing.

Treating GSTR-2B as if it behaves like a live return instead of a period-specific reference file.

It is the control file that reconciliation starts from, because it reflects what the business expects to claim.

Assuming the register is clean enough to compare without normalizing invoice numbers, GSTINs, and duplicate rows.

It is the reference point for what the business expects to claim.

Treating the books-side data as automatically correct without checking the portal comparison.

It is the other half of the reconciliation comparison and often explains timing differences.

Ignoring portal-side timing because the books already show the invoice.

It prevents filing decisions from being made on incomplete or conflicting data.

Reducing reconciliation to a single value check instead of invoice-level and tax-component-level validation.

Normalization reduces false mismatches and improves matching accuracy.

Starting the match before the input fields are standardized.

It is often the difference between a clean match and a false exception.

Using raw invoice strings as the only matching key.

Without the correct mapping, the comparison logic reads the wrong values.

Assuming every export uses the same header names.

A reconciliation mismatch becomes operationally important only when it affects recoverable ITC.

Using the term loosely without checking the invoice period, vendor status, and tax component match.

Risk ranking drives the order of review and the urgency of follow-up.

Treating every exception as equally urgent.

It separates claimable credit from items that should stay on hold.

Calling every booked tax amount recoverable before the reconciliation step is complete.

It prevents the team from over-claiming credit and creating filing risk.

Leaving non-recoverable items mixed into the matched queue.

It is the core operational issue SaralKar is designed to isolate, prioritize, and resolve.

Grouping all mismatches together instead of separating missing invoices, tax deltas, and duplicate claims.

It helps the team focus on material exceptions first while preserving audit discipline.

Approving all small deltas without confirming the root cause.

A GSTIN mismatch can block an otherwise valid invoice from matching cleanly.

Fixing the invoice row without checking whether the vendor master data is also wrong.

It often signals a missing vendor filing or a period mismatch that affects ITC timing.

Treating every books-only row as permanently unrecoverable.

It can indicate a missing booking, a timing issue, or a vendor entry that needs validation.

Ignoring portal-only invoices because they are not in the books yet.

It can directly delay or block the intended ITC claim.

Assuming the invoice is invalid instead of checking vendor filing status.

It can inflate claim values and create false matched counts.

Cleaning duplicates without verifying whether one entry is a correction note.

Even a small difference can change the filing position or require review.

Checking only the taxable amount and ignoring the component split.

It should be treated as a minor review item, not a high-risk mismatch.

Escalating every small delta as if it were a filing blocker.

Date drift can move the invoice into the wrong filing period.

Ignoring the date field because the invoice number matches.

The match result determines whether the invoice goes straight to approval or into review.

Relying on invoice number alone, which fails when vendors format numbers differently.

It is the cleanest form of confirmation and should move directly to the matched queue.

Forcing exact match logic on data that contains known rounding or formatting noise.

It captures the real-world cases where vendor formatting changes without changing the underlying transaction.

Allowing fuzzy logic to become too loose and create false positives.

It separates rounding noise from genuine mismatch risk.

Using percentage-based tolerance without checking invoice size and tax component impact.

Bad master data creates false mismatches even when the invoice is valid.

Treating master data cleanup as a separate task instead of a prerequisite for matching.

It creates false visual mismatches and makes manual review slower.

Using vendor display name as the sole identity key.

It is where the control work happens and where review time should be focused.

Mixing high-risk cases with low-risk minor differences.

It ensures the team works on the most important cases first.

Reviewing exceptions in the order they appear instead of by risk.

It turns reconciliation into an accountable decision.

Calling the file complete before the reviewer has confirmed the exceptions.

Duplicates can cause a double claim or distort the exception queue.

Removing duplicates by eye without checking whether they are genuine credit-note adjustments.

Reconciliation is one of the control gates inside the close.

Using the phrase loosely without defining the control steps.

It is often the practical way to clear a books-only or missing-invoice exception.

Sending generic reminders without the exact invoice details the vendor needs.

It keeps the filing decision tied to a repeatable control step.

Running the comparison too early and then filing from stale data.

It gives the team a clear deadline for closing exceptions before filing.

Having no published target for exception clearance.

It lets teams explain how the filing position was reached after the fact.

Only saving the final workbook and discarding the reasoning behind the decisions.

It is the difference between a completed task and a defensible control.

Saving no evidence beyond the final report.

It is the artifact the reviewer uses to make the filing decision.

Making the report so raw that it still needs manual formatting before use.

It builds trust by showing the output structure before the final action.

Hiding the output shape behind a generic download button.

It is the difference between a file that looks complete and a file that is operationally useful.

Equating technical completion with review readiness.

It can explain why a matched row now has a small difference or a lower claimable amount.

Treating the reduced value as a mismatch without checking the adjustment document.

It can create a portal-side or books-side value difference that needs explanation.

Assuming every increased value is a data-entry error.

Reconciliation must verify the IGST amount separately rather than hiding it inside a total.

Treating the tax total as enough evidence that the row matches.

The CGST component can differ even when the total value looks similar.

Ignoring the CGST line because the total invoice value looks correct.

It is one half of the same-state tax split and must be validated separately.

Focusing only on taxable value and ignoring the SGST line item.