Building compliant SaaS for India: GST e-invoicing, DPDP Act and UPI payments

01GST e-invoicing is a system integration, not an invoice template

Above the applicable turnover threshold, B2B invoices must be registered with the Invoice Registration Portal before they are legally valid. The IRP returns an Invoice Reference Number and a signed QR code, and an invoice without them is not a compliant tax document.

This makes invoice generation a synchronous dependency on external government infrastructure - which has downtime, rate limits and schema versions. Any billing system serving Indian B2B customers needs to treat IRN registration as a first-class, retryable workflow with its own state machine, not as a formatting step at the end of billing.

• IRN registration must succeed before an invoice is legally valid.
• Design as a retryable workflow with explicit pending/registered/failed states.
• Handle IRP downtime without blocking the billing run or losing invoices.
• Store the signed QR payload and IRN against the invoice record permanently.
• Cancellation has a strict time window - model it explicitly.

02Place of supply drives the tax calculation

Indian GST splits into CGST plus SGST for intra-state supply and IGST for inter-state, and which applies depends on place-of-supply rules rather than simply the customer's billing address. For services, the rules turn on the recipient's registered location and whether they hold a GSTIN.

This breaks the common SaaS assumption that a single tax rate can be attached to a country. You need the customer's GSTIN, their state, and the supply classification stored as structured fields, with the split computed per line item at invoice time.

03The DPDP Act changes consent handling

The Digital Personal Data Protection Act establishes a consent-based regime with notice requirements, purpose limitation and data principal rights including correction and erasure. It is broadly familiar if you have implemented GDPR, but the mechanics differ enough that a copied implementation will not satisfy it.

The practical requirement is a consent record that is itemised by purpose, versioned, timestamped, and withdrawable - and a system that actually honours withdrawal by stopping the corresponding processing. A single boolean 'accepted terms' column does not meet this standard.

• Itemised consent per purpose, not one blanket acceptance.
• Versioned and timestamped consent records, retained as evidence.
• Withdrawal must be as easy as granting, and must actually stop processing.
• Notice in clear language, available in the languages you serve.

04UPI, recurring payments and reconciliation

UPI dominates Indian digital payments and behaves differently from card rails. Recurring billing runs through UPI Autopay mandates with their own registration, modification and revocation flows. Cards additionally require tokenisation, and RBI rules on stored credentials mean you cannot retain raw card data the way many global systems assume.

Reconciliation is the operational reality that catches teams out. UPI settlement timing, partial failures and payment status that resolves asynchronously mean your billing system needs a reconciliation loop that treats the payment provider as the source of truth and can correct its own state after the fact.