Tax & Revenue

GSTN is one of the world's most complex tax technology platforms. Scale: 1.4 crore registered taxpayers, 1.4B+ invoices/month, peak load during filing deadlines (11th and 20th of each month). Architecture: 1) Distributed Processing: Invoice data is partitioned by state (37 states/UTs). Each state's data processed independently. Cross-state matching (IGST) requires inter-partition joins. 2) Batch + Real-time: E-invoicing is real-time (IRP validates and returns IRN in < 2 seconds). Return filing is batch — GSTR-1 data uploaded in bulk, processed in parallel. GSTR-2B (buyer's view) generated as a batch job after GSTR-1 filing deadline. 3) Database: Oracle for transactional data, MongoDB for invoice documents (flexible schema — invoices have varied line items), Hadoop cluster for analytics and cross-matching. 4) Filing Deadline Spike: 70%+ of returns filed in last 3 days before deadline. System scales horizontally — additional compute nodes brought online. Queue-based processing prevents system overload. 5) API Architecture: GSP (GST Suvidha Providers) like ClearTax, Tally connect via standardized APIs. Rate limiting per GSP. Async filing — submit → get token → poll for status. 6) Reconciliation Engine: Matches seller's GSTR-1 invoices with buyer's purchase data. Generates GSTR-2B automatically. Handles mismatches: amount differences, missing invoices, late filing by suppliers. This reconciliation across 1.4B invoices is one of the largest data matching operations in the world.

Tax law changes frequently — GST rates revised, new exemptions added, thresholds updated. Hardcoding tax rules in application code is unmaintainable. Solution: Business Rule Management System (BRMS). Architecture: 1) Rule Engine: Use Drools (Java) or custom DSL. Tax rules expressed as: IF (HSN code IN [1001-1005]) AND (transaction type = 'B2B') AND (inter-state = true) THEN tax_rate = 5% AND tax_type = 'IGST'. 2) Rule Versioning: Each rule has effective_from and effective_to dates. On a given transaction date, the engine picks the applicable version. Historical transactions always compute with the rule version active at that time. 3) Rule Hierarchy: Central GST rules (CGST Act), State-specific rules (SGST variations), Industry exemptions, Special economic zone rules. Rules evaluated in priority order with override capability. 4) Testing: Every rule change goes through regression testing — run all existing transactions through new rules, compare results. If output changes unexpectedly, alert. 5) Deployment: Rules deployed independently of application code. Rule file (DRL in Drools, or JSON config) pushed to rule engine. Hot-reload without application restart. 6) Audit Trail: Every rule execution logged: transaction → rules applied → computation result. Required for tax audit compliance. Example: GST Council meets quarterly and may change 50+ rules. With BRMS, rule analysts update the rule files, test, and deploy — no developer code change needed.

GST fraud often involves networks of companies creating fake invoices to claim fraudulent ITC (Input Tax Credit). Graph analysis is the most effective detection method. Types of fraud: 1) Circular Trading: A sells to B, B sells to C, C sells back to A (or to A's related entity). Goods never actually move. Each entity claims ITC on purchases. Net effect: government loses tax revenue. 2) Fake Invoice Factories: Shell companies (registered but no real business) issue invoices to multiple genuine businesses. Genuine businesses claim ITC on these fake invoices. Shell company collects fee (2-5% of invoice value) and disappears. Graph Detection: Model: Each GSTIN is a node. Each invoice is an edge. Build directed graph of all B2B transactions. Algorithms: a) Cycle detection (DFS/Tarjan's) — find cycles (A→B→C→A). Flag if goods description is similar across cycle (same goods 'moving' in circles). b) Community detection — find clusters of GSTINs transacting mostly with each other (closed groups are suspicious). c) Centrality analysis — shell companies often have high betweenness centrality (they connect many otherwise unconnected businesses). d) Temporal analysis — fake invoice chains often created in short burst (all in last week of month before GSTR-3B deadline). Red flags: New registration + high-value transactions immediately. GSTIN with many buyers but no purchases (or vice versa). Concentration — 90%+ of a company's purchases from a single supplier. Implementation: Neo4j for graph storage and query. Python NetworkX for algorithm prototyping. Apache Spark GraphX for large-scale processing. India's GSTN analytics team has recovered ₹1,000+ crore using these techniques.

Tax Computation: Determining the correct tax amount for a single transaction. Challenge: Multiple tax types (GST, TDS, customs), complex rules (exemptions, thresholds, place of supply), real-time requirement (customer checkout). Technology: Rule engine evaluates transaction attributes → determines applicable tax rate and type → computes amount. Must be fast (< 50ms for POS/e-commerce). Avalara and Vertex specialize in this — their APIs return tax computation for any transaction. Tax Compliance: Aggregating all transactions, preparing returns, filing with authorities, reconciling, and maintaining audit trail. Challenge: Monthly/quarterly deadlines, matching with government data, handling amendments, managing multiple entity/state registrations. Technology: ERP/accounting data → ETL pipeline → tax return preparation engine → validation → filing via government API → status tracking → reconciliation. ClearTax and Thomson Reuters ONESOURCE specialize in this. Key difference: Computation is real-time per-transaction (milliseconds). Compliance is batch periodic (monthly/quarterly, processing millions of transactions). Architecture difference: Computation = low-latency API with cached rules. Compliance = batch processing pipeline with state management, reconciliation engine, and filing queue. Example: When you buy on Amazon, Avalara computes GST in real-time (computation). At month-end, Amazon's tax team uses ClearTax to aggregate all transactions, reconcile ITC, and file GSTR-1 and GSTR-3B (compliance).

India's e-invoicing is a government-mandated system where B2B invoices above a threshold (currently ₹5 Cr annual turnover) must be registered with the Invoice Registration Portal (IRP) before being shared with buyers. Technical Flow: 1) Seller ERP generates invoice in prescribed JSON Schema (IRN schema — ~50 mandatory fields). 2) ERP calls IRP API with signed invoice JSON. 3) IRP validates: GSTIN active, HSN valid, no duplicate (seller GSTIN + doc no + FY is unique), tax computation correct. 4) IRP generates: IRN (Invoice Reference Number — unique hash), QR code (contains key invoice data for offline verification), Digital signature (government PKI). 5) IRP pushes to: GSTN (auto-populates GSTR-1), E-Way Bill portal (auto-generates Part A if goods involved). Technical Challenges: 1) Latency: IRP must respond in < 2 seconds. Millions of invoices/day. Caching, horizontal scaling, and efficient validation critical. 2) Idempotency: If ERP call times out, retry must not create duplicate IRN. IRP uses seller GSTIN + document no + FY as idempotency key. 3) Schema Validation: JSON schema is complex and changes periodically. ERP software must update schema validation. Common errors: wrong HSN code length, missing mandatory fields, incorrect tax calculation. 4) Offline Handling: What if IRP is down? Regulations allow invoice generation with 'pending IRN' status. Must register within 24 hours. ERP queues failed e-invoices for retry. 5) Cancellation: E-invoice can be cancelled within 24 hours via IRP. After 24 hours, must issue credit note instead. ERP must enforce this time-based logic. 6) Multi-IRP: Government has authorized multiple IRPs for redundancy. ERP should implement failover — if IRP-1 is slow, route to IRP-2.