GSTR‑2B Reconciliation in GSTBot: Configurable Tolerances

#python #react #fastapi #postgres

GSTR‑2B Reconciliation in GSTBot: Configurable Tolerances

Manual reconciliation of the GSTR‑2B feed against a business’s purchase register is a repetitive task that consumes time and is error‑prone. Small‑to‑medium enterprises (SMEs) in India must match every vendor entry, GSTIN, invoice number, amount, tax rate and HSN code, and any mismatch can delay filing or trigger penalties. GSTBot addresses this pain point by automating the entire workflow and, crucially, by allowing a configurable tolerance layer that replaces brittle exact string matching. This is where gst reconciliation software pays off in practice.

The Reconciliation Engine

At the heart of GSTBot’s reconciliation engine is a Python module that loads the extracted invoice data into a PostgreSQL table, and a Celery worker that processes each batch. The worker pulls a set of invoices from a Redis queue, performs the matching logic, and writes a reconciliation report back to the database. A simplified view of the worker looks like this:

# reconcile_worker.py
from celery import shared_task
import sqlalchemy as sa
from tolerance import match_invoice

@shared_task
def reconcile_batch(batch_id: int):
    conn = sa.create_engine("postgresql://user:pass@db/gstbot").connect()
    invoices = conn.execute(sa.text(
        "SELECT * FROM invoices WHERE batch_id = :bid"
    ), bid=batch_id).fetchall()

    gstr2b = conn.execute(sa.text(
        "SELECT * FROM gstr2b WHERE month = :m"
    ), m=invoices[0].month).fetchall()

    results = []
    for inv in invoices:
        match = match_invoice(inv, gstr2b, config.tolerances)
        results.append(match)

    conn.execute(sa.text(
        "INSERT INTO reconciliation_results (batch_id, results) VALUES (:bid, :res)"
    ), bid=batch_id, res=results)

The match_invoice function embodies the tolerance logic. It compares each field of the invoice to the corresponding GSTR‑2B record, but it does so with a user‑configurable tolerance dictionary:

# tolerance.py
def match_invoice(inv, gstr2b_records, tolerances):
    for rec in gstr2b_records:
        if (
            rec.gstin == inv.gstin and
            rec.invoice_number == inv.invoice_number and
            abs(rec.amount - inv.amount) <= tolerances['amount'] and
            rec.tax_rate == inv.tax_rate and
            rec.hsn == inv.hsn
        ):
            return {'status': 'matched', 'record_id': rec.id}
    return {'status': 'unmatched', 'reason': 'no match'}

If the user sets tolerances['amount'] to 5.0, the engine will accept invoices that differ by up to five rupees in the taxable value, accommodating common rounding discrepancies that would otherwise flag a mismatch. Getting gst reconciliation software right early saves rework later.

Configurable Tolerances in the UI

The React front‑end exposes a simple form where finance staff can tweak the tolerance thresholds. The form is built with Vite‑powered React and communicates with a FastAPI endpoint that validates and persists the settings:

// ToleranceForm.tsx
const [tolerances, setTolerances] = useState({ amount: 0, tax_rate: 0 });

const handleSubmit = async () => {
  await fetch('/api/tolerances', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(tolerances)
  });
};

The FastAPI handler updates a tolerances table in PostgreSQL, and the Celery workers read the latest configuration before each reconciliation cycle. This decoupling ensures that a change in tolerance does not require a redeploy of the worker code.

Result Presentation

Once the batch is processed, the reconciliation report is rendered in a React table. Each row shows the vendor, invoice number, the matched status, and a “Recommended Action” column. Unmatched entries are flagged with a tooltip that explains whether the mismatch was due to a missing GSTR‑2B record, a numeric discrepancy beyond the tolerance, or a tax‑rate mismatch.

// ReconciliationTable.tsx
{results.map(r => (
  <tr key={r.id}>
    <td>{r.vendor}</td>
    <td>{r.invoice_number}</td>
    <td>{r.status}</td>
    <td>{r.recommended_action}</td>
  </tr>
))}

This visual feedback turns a laborious spreadsheet exercise into a single‑screen review, enabling finance teams to approve or flag exceptions in minutes. Good gst reconciliation software keeps the rest of the workflow predictable.

Why Tolerances Matter

Exact string matching forces every minor variation—leading zeros, case differences, or a one‑rupee rounding error—to trigger a mismatch. In practice, these variations are common when vendors send invoices in different formats or when the GSTR‑2B feed contains typos. By allowing configurable tolerances, GSTBot reduces the volume of false positives, streamlines the filing checklist, and keeps the ITC (Input Tax Credit) reconciliation process accurate.

The feature is a core part of GSTBot’s positioning as a “gst software for small business india” that delivers “gst compliance automation” without the enterprise price tag. It complements other capabilities such as rule‑based reversal tracking, supplier health scoring, and portal data preparation, but the tolerance‑based reconciliation is the linchpin that turns bulk invoice intake into actionable compliance data.

Bottom Line

For engineers building or evaluating GST compliance tools, the tolerance‑enabled GSTR‑2B reconciliation in GSTBot demonstrates how a modest change in matching logic can eliminate a significant source of friction for Indian SMBs. The implementation—Python, PostgreSQL, Redis, Celery, FastAPI, and React—leverages well‑known libraries to deliver a reliable, maintainable solution that can be extended with additional matching heuristics or integrated into broader ERP workflows.

DEV Community

GSTR‑2B Reconciliation in GSTBot: Configurable Tolerances