B2C/B2B compliance pack — GST invoicing, DPDP/GDPR, policies, DPAs

Why / Context

Explicitly deferred to post-MVP by founder decision ("the B2C/B2B compliance stuff can be post-MVP"). PRD §9.6 makes DPDP/GDPR-class handling "a real gating factor in winning institutional contracts." This pack covers: GST invoicing done properly (B2C + B2B), India DPDP Act + GDPR-class rights, policy pages, and enterprise DPAs. Schema hooks were pre-built so none of this restructures production.

Schema already in place — NO migration required

• Invoice.kind (TAX_INVOICE|CREDIT_NOTE) + refundId + InvoiceSeries (gapless per-series numbering)
• Order.billTo Json (incl. buyer GSTIN), OrderItem.taxMinor/taxRateBps, Tenant.gstin
• User.anonymizedAt (erasure = overwrite-PII-in-place), User.marketingOptIn
• NotificationPreference (consent per channel), AuditLog (processing records)
• PlatformConfig: commerce.gstRateBps, commerce.pricesIncludeTax

Implementation plan

1. GST invoice engine: proper tax-invoice fields (supplier GSTIN, place of supply, SAC code for online education, CGST/SGST vs IGST split by state, buyer GSTIN for B2B) rendered into Invoice.data + PDF; credit notes on refunds (kind CREDIT_NOTE, refs the refund) — numbering via InvoiceSeries transactional counter.
2. GST filings export: monthly GSTR-1-shaped CSV (B2B/B2C splits) for the accountant; reconciliation vs ledger.
3. Marketplace tax note: legal review of platform-vs-creator supply chain (who invoices the learner — platform as e-commerce operator w/ TCS u/s 52?); implement the counsel's answer behind the invoice service so either mode is emittable. Get counsel sign-off before GA.
4. DPDP/GDPR rights: self-serve data export (JSON bundle of the learner's data), erasure request flow → grace period → anonymization job (overwrite PII fields, set anonymizedAt, cascade to portfolio/discussions display names) — FKs preserved by design.
5. Consent: cookie banner (gates PostHog client capture, issue #12), marketing consent capture at signup (marketingOptIn), consent-change audit entries.
6. Retention: documented schedule + scheduled purge jobs (expired sessions, stale carts, old webhook payload bodies) — additive config only.
7. Policy surfaces: ToS, Privacy, Refund policy page stating the 14-day guarded window verbatim (a trust asset per teardown — link it from every checkout), cookie policy; versioned acceptance (AuditLog on signup with policy version).
8. Enterprise DPA template + subprocessor list page (Supabase, Netlify, Fermion, Razorpay/Dodo, Resend/Novu, Sentry/PostHog).
9. Security page: responsible-disclosure contact, data-location statement.

Acceptance criteria

• B2B order with GSTIN yields a compliant tax invoice (IGST/CGST split by state) and a credit note on refund, gaplessly numbered
• GSTR-1 export reconciles with the ledger for a test month
• Erasure request anonymizes a user without breaking enrollments/reviews/orders (FKs intact)
• Data export bundle downloads with all personal data categories
• Checkout links the refund policy; policy acceptance versioned

Dependencies / sequencing

• Builds on MVP M7 invoice rows; tax-counsel engagement is the long pole — start early
• Blocks enterprise GA (#17) contracts requiring DPAs

Scope update (2026-07-17 triage, see #42)

The GST invoice engine (task 1) + filings export (task 2) moved PRE-LAUNCH by founder decision — tracked under #36/#42 Tier 0. Remaining here post-MVP: marketplace tax counsel question (task 3), DPDP/GDPR-class rights tooling beyond the launch-window basics, enterprise DPAs, policy localization.

Start by reading the implementation plan and the existing Invoice, InvoiceSeries, Order, User, PlatformConfig, and AuditLog schema hooks. Review the sequencing around #36, #42, and #17, and resolve the tax-counsel dependency before implementation. Done means the listed invoice, export, erasure, data-export, and policy-link acceptance criteria are met without breaking foreign keys.