In-Line Fiscal Clearance

A platform issues B2B invoices in a market where each invoice must be registered with a government portal before it is valid, and the portal returns a reference number the invoice must carry. This is not an integration that can be made asynchronous by choice: without the reference, the document is not a tax invoice.

India's GST e-invoicing regime is the documented instance. Notification 10/2023 – Central Tax lowered the threshold to businesses with aggregate turnover above ₹5 crore from 1 August 2023, following earlier phases at higher thresholds. Covered businesses upload the invoice to an Invoice Registration Portal, which returns an Invoice Reference Number, a digitally signed invoice and a QR code. Several other jurisdictions operate structurally similar clearance regimes.

Why it matters

Three properties follow, and each one breaks a common design assumption.

The reference is required for validity, not for reporting, so the invoice cannot be sent to the customer and often cannot be recognised in revenue until clearance succeeds. A design that treats the portal as a downstream reporting hop will eventually issue an invalid invoice.

The dependency's availability is not yours. Plan for multi-hour unavailability, including at month end when every covered business in the jurisdiction is submitting; a queue sized for 2 hours of backlog at peak issuance rate is the minimum, and 24 hours is the figure to design for.

Submission must be exactly-once in effect, because a duplicate registration is a tax problem requiring a credit note and an explanation, not a software problem you can retry away.

Implementation patterns

• Separate document creation from clearance. Create the invoice internally with a stable local number and a state of awaiting_clearance, then clear through a queue with retries, gating the customer-facing step on state rather than on a synchronous call.
• Idempotency on your own document number, with the portal's response retained as the authoritative artefact.
• Query before resubmitting after an ambiguous timeout, to find an existing registration. Never retry a tax submission blind.
• Prioritise the queue by regulatory deadline, not first-in-first-out, because the clock is set in law relative to the invoice date.
• Treat rejections as a business flow. Most are master-data problems — a counterparty's tax identifier, a tax code, a unit of measure — so they must reach someone who can correct the data rather than a dead-letter queue.
• Keep an evidence store: submission payload, signed response, timestamps, retained for the statutory period, because the audit asks what you submitted and when.
• Monitor clock skew, since a signed payload with a timestamp outside the portal's tolerance is rejected despite being correct.
• Watch the threshold. The obligation arrives with turnover growth rather than with a decision, so a monitored trigger on the threshold is part of the architecture.

Industry example

Beyond India's IRP model, Italy's SDI has required clearance of domestic B2B invoices through a state exchange since 2019, and several Latin American regimes have operated authorisation models for longer still. The EU's VAT in the Digital Age package extends digital reporting obligations further. The pattern for an architect is the convergence rather than any single regime: clearance-at-issuance is becoming the default shape of invoicing obligations, and systems built on the assumption that tax reporting is a batch at month end are accumulating a rewrite.

Failure scenarios

• Blind retries creating duplicate registrations, resolved only by a credit note.
• Invoices stuck in awaiting_clearance with no queue owner, discovered at month end when revenue does not reconcile.
• A portal schema change on a government timetable, which is a hard external deadline you did not set and cannot negotiate.
• A canonical cross-market invoice model that cannot express one jurisdiction's mandatory field, so the market with the deadline waits for a model change.
• Clock skew rejections that look like a portal outage and are a local NTP problem.
• Crossing the threshold unnoticed, so the first non-compliant invoice is issued by a business that grew into the obligation.

Trade-offs

What the design buys is an invoicing flow that survives the portal being down and never issues an invalid document. What it pays is a state machine on the invoice, a queue, a reconciliation job against the portal's records, a support process for rejections, and a per-market adapter rather than one canonical implementation — which is the uncomfortable part, because clearance regimes differ enough in mandatory fields and semantics that a shared canonical model becomes the constraint rather than the simplification.

When not to use it

Where the obligation is genuinely periodic reporting rather than per-document clearance, do not put the regulator on the transaction path: batch, reconcile and submit on schedule, which is simpler and sufficient. Below the turnover threshold, the correct architecture is none of this plus a monitored trigger. And for a single-market business with modest volume, a certified third-party clearance provider removes most of this work in exchange for a dependency and a fee, which is usually the right trade until invoice volume makes the fee material.

Interview question

Q: Your product is expanding into a market with mandatory invoice clearance. The existing invoicing service calls a tax-calculation API synchronously and emails the invoice in the same request. Walk me through what has to change, and what you would tell the product manager about the customer-visible behaviour.

What a strong answer covers: identifying validity-at-issuance as the property that forces the redesign, rather than treating the portal as another API call · the state machine and queue, with the customer-facing step gated on state · idempotency on your own document number and the query-before-resubmit rule, with the reason stated in tax terms · deadline-ordered queueing because the clock is legal rather than technical · rejections as a master-data workflow with a human owner · the evidence store and its retention · and telling the product manager honestly that invoice delivery becomes eventually-consistent, with a status the customer can see.

Quick check

Quiz: Why is a blind retry of a cleared-invoice submission dangerous? — Because it can create a second registration of the same invoice, which is a tax defect requiring a credit note rather than an error you can discard; query for an existing registration first.

Flashcard: What ordering should a clearance queue use, and why not FIFO? — Order by regulatory deadline, because the clock is set in law relative to each invoice's date, so the oldest unsubmitted invoice is not necessarily the most urgent.