Simple Invoice Processing

The Problem

Accounts payable teams at mid-market companies typically receive invoices from three to five distinct vendor categories in a single processing cycle: domestic GST-registered suppliers with multi-rate line items, inter-state vendors where the correct tax type (IGST vs. CGST+SGST) depends on a state-code cross-check, and international vendors whose EUR- or USD-denominated invoices carry no GSTIN and no Indian tax fields at all. Processing these manually means an AP clerk must read the vendor GSTIN, extract the state code, compare it against the declared place of supply, sum every line amount independently, and verify that each line's tax amount equals line_amount × tax_rate ÷ 100 — all before keying the invoice into the ERP. At 50 invoices per month that routine consumes roughly two full working days; at 200 invoices it becomes a part-time role.

The math-check problem alone is significant. A single vendor invoice like the Synapse Digital Services bill (INV SDS/2025/INV-107) carries five line items taxed at four different rates — 18%, 12%, 5%, and 0% (zero-rated export documentation) — with an aggregate tax of ₹20,300. Verifying that figure manually requires four separate multiplication operations and one summation. Any one of those steps can introduce a keying error that is invisible until the GSTR-2B auto-populated credit diverges from the purchase register, at which point Section 16(2)(aa) of the CGST Act, 2017 restricts the Input Tax Credit claim to the amount reflected in the supplier's filed return — meaning an over-claimed or mis-booked ITC must be reversed, often with interest under Section 50.

International invoices compound the problem differently. A EUR-denominated invoice from a US-registered vendor to a German entity carries no GSTIN, no place of supply, and no tax-rate fields. A validation ruleset built only for GST invoices will either crash on null fields or generate false-positive errors that an AP clerk must clear one by one, adding noise to the exception queue and delaying payment runs.

The scale-break point for most mid-market finance teams is approximately 80–100 invoices per month processed by a single AP resource. Beyond that volume, the error rate on manual math verification and GSTIN state-code checks rises faster than headcount can compensate, and the downstream cost — ITC mismatches, duplicate payments, and vendor disputes — becomes material.

Why It Matters: Context

Under the GST framework, every tax invoice from a registered supplier must comply with Rule 46 of the CGST Rules, 2017, which mandates that the invoice carry the supplier's GSTIN, the recipient's GSTIN, the place of supply, the applicable HSN or SAC code, and a separate tax amount for each rate slab. The place of supply determines the tax type: where the supplier's state code (the first two digits of the GSTIN) matches the place of supply state code, the transaction is intra-state and attracts CGST+SGST; where they differ, it is inter-state and attracts IGST under Section 5 of the IGST Act, 2017. Booking the wrong tax type — for example, booking CGST+SGST on what is actually an inter-state supply — creates a reconciliation mismatch in GSTR-2B that the AP team must correct before filing GSTR-3B, with the risk of a demand notice under Section 73 or 74 of the CGST Act if the error is not caught in the same return period.

For mid-market companies without a dedicated GST compliance team, these checks are done ad hoc by the same AP resource processing the invoice. The practical reality is that a controller managing 150 vendor invoices a month across domestic and international suppliers has no standardized extraction template: some vendors supply PDFs with embedded text, others supply scanned images with embossed seals, and international suppliers follow their own national invoice formats (e.g., German Rechnung layouts under the EU VAT Directive 2006/112/EC) that share no field labels with a GST tax invoice. Reconciling these formats manually, without a structured extraction layer, means the data that enters the ERP is only as accurate as the clerk's reading of the source document.

The specific failure consequence is a duplicate payment or an ITC reversal. Duplicate payments occur when the same invoice number is re-submitted in a subsequent batch — a common vendor error — and the AP team has no automated check against previously processed invoice numbers for the same GSTIN. ITC reversals occur when a math error in the tax amount field is booked without verification, the credit is claimed in GSTR-3B, and the supplier's filed GSTR-1 reflects a different amount, triggering an auto-populated discrepancy in GSTR-2B that the taxpayer must address under Rule 37A of the CGST Rules.

What This Workflow Automates

1. Document ingestion and format detection: The workflow accepts PDF invoices — whether digitally generated or scanned — and identifies the document type as Invoice, routing it to the appropriate extraction schema regardless of whether the source is a domestic GST-registered entity or a foreign vendor with no Indian tax fields.
2. Structured field extraction: For each invoice, the workflow extracts invoice_number, invoice_date, vendor_name, vendor_gstin, vendor_address, customer_name, customer_gstin, customer_address, place_of_supply, currency, incoterm, subtotal, tax_amount, and total_amount at the header level.
3. Line-item extraction: For every line on the invoice, the workflow extracts line_number, item_code (HSN/SAC where present), description, quantity, unit, unit_price, line_amount, tax_rate, and tax_amount as a structured array — preserving mixed-rate line items as distinct records.
4. Math validation — line-level tax check: For each line item carrying a non-null tax_rate and line_amount, the workflow computes the expected tax as line_amount × tax_rate ÷ 100 and compares it to the extracted tax_amount; any discrepancy raises a line-level validation exception.
5. Math validation — subtotal vs. line-item sum: The workflow sums all extracted line_amount values and compares the result to the header-level subtotal field, flagging the invoice if the difference is non-zero.
6. GST compliance checks (domestic invoices only): Where both vendor_gstin and customer_gstin are present, the workflow extracts the supplier state code from the first two digits of the vendor GSTIN and compares it to the state code in the declared place_of_supply, surfacing any inter-state/intra-state mismatch as a flagged field for AP review before tax-type booking.
7. International invoice handling: Where vendor_gstin and customer_gstin are both null — as with EUR- or USD-denominated foreign vendor invoices — the workflow bypasses all GST-specific validations and extracts only the available fields (currency, line items, subtotal, total) without raising false-positive errors on absent tax fields.
8. Unreadable document flagging: Where OCR yields no extractable structured fields (e.g., a dense, seal-stamped scanned invoice), the workflow returns an empty extracted_fields object and records the file as requiring manual review, preventing a silent null-record from passing downstream to the ERP.

All eight steps execute in under 30 seconds per invoice batch, producing a structured JSON output with deterministic field values and a discrete validation-results array that every AP controller can audit line by line.

Edge Cases We Simulate

The workflow ships with a battery of synthetic test scenarios that exercise every failure mode we have seen in real-world data. Each scenario produces a deterministic outcome that an auditor or controller can verify in seconds.

Sample Documents

Download or inspect the seeded sample files used to demonstrate this workflow:

Sample Results

Running the workflow across the four demo invoices produced structured extraction on three of four documents. The Zenith Realty invoice (ZRD/2025/INV-201, INR ₹289,100) extracted all three line items — Office Space Rent at ₹180,000, Common Area Maintenance at ₹25,000, and Electricity Reimbursement at ₹40,000 — each at an 18% GST rate, with a header tax amount of ₹44,100 recorded for cross-check. The Synapse Digital Services invoice (SDS/2025/INV-107, INR ₹165,300) extracted five line items across four tax rate slabs (18%, 12%, 5%, and 0%), with SAC codes 998313, 998315, 998221, 998316, and 998399 recorded per line — the zero-rated export documentation line (₹15,000, SAC 998399) extracted cleanly with a tax_rate of 0.0 and tax_amount of 0.0, confirming the workflow does not misclassify a nil-tax line as a missing-field error. The German invoice (DEMS3310-PW-2, EUR €300) extracted vendor address, customer address, subscription period, and total amount without raising any GST validation errors, confirming the null-GSTIN bypass path operates correctly.

The fourth file — dsg_invoice_25rows_seal.pdf, a dense 25-row document with an embossed company seal — returned an empty extracted_fields object, demonstrating the unreadable-document exception class: rather than posting a null or partial record to the ERP, the workflow surfaces the file explicitly for manual review. This is the specific exception class that causes silent data-quality failures when invoices are processed without a structured extraction layer — a partially extracted invoice with a null total_amount that reaches the ERP unchecked can result in a zero-value posting or a duplicate payment if the vendor resubmits the same invoice in the next cycle.

Why Automation Wins Here

For a mid-market AP team processing 100 domestic and international invoices per month, the workflow replaces an estimated 12–15 hours of manual field extraction, math verification, and GSTIN state-code checking with a process that runs in under 30 seconds per document. The math validation step — computing line_amount × tax_rate ÷ 100 for every line and comparing the aggregate to the header tax field — catches arithmetic discrepancies that are invisible to a clerk reading the printed total, reducing the probability of an ITC booking error that would require reversal under Rule 37A of the CGST Rules. The null-GSTIN detection path eliminates false-positive exceptions on international invoices, keeping the exception queue limited to genuine anomalies rather than format-driven noise.

Every processed invoice produces a structured JSON artifact containing the full extracted-fields object and a discrete validation_results array. This artifact is directly attachable to the AP voucher in the audit file: the controller can demonstrate, for any invoice, exactly which fields were extracted, which math checks were run, and which exceptions — if any — were raised before the invoice was posted. For internal auditors applying ICAI SA 500 (Audit Evidence) standards, a machine-generated extraction log with a timestamped validation result provides a more reproducible evidence trail than a manually annotated invoice printout.

Frequently Asked Questions