Skip to content
CogniYukti

Billing

“Is this one in scope?” is not a question a finance team should answer per invoice.

It depends on the entity, the turnover and the threshold, and it changes when any of the three moves. Left to a person, it becomes a checkbox somebody ticks from habit — until the year they cross a line nobody was watching.

The decision

Made at finalising, with both numbers kept.

Inside the same act that finalises the invoice: check the issuing entity's tax regime, then either an explicit setting or your own rolling twelve-month turnover against the threshold in force.

Which reason applied is recorded on the invoice, with both figures. Not a flag — the turnover it was measured against and the threshold it was compared to.

Recorded on the invoiceWhy this one was reported
Entity's tax regime
goods and services
Your rolling twelve months
₹7,41,20,000
Threshold in force
₹5,00,00,000
Decision
reported — over threshold
Turnover counts only invoices that actually stand — drafts, voids and write-offs are excluded. So the number the decision was made on is the number you could defend.
Illustrative
  • Turnover counts only invoices that stand

    Drafts, voids and write-offs are excluded — so the figure the decision rests on is one you could defend.

  • A failure never costs you the invoice

    If the reporting call fails, the invoice is still finalised and the failure is recorded for the retry sweep. Finance does not stop because a third party is having a bad morning.

  • Switched on with nothing configured says so

    Rather than quietly doing nothing, the invoice is marked as pending with the reason written on it.

Before calling out

It validates against the authority's own rules first.

The registration number against its real format. The seller's state and postcode. A classification code on every line. A quantity above zero. And the tax rate against the set the authority actually accepts — a rate that is not one of them is refused here rather than by them.

The reason is stated in the code: a rejected submission costs a rate-limited round trip, and every avoidable one is worth catching first.

Errors name the field, so the message reads as missing classification code on line two rather than a reference number you have to look up.

  • The totals must reconcile before it goes

    The header against the sum of the lines, within a rounding unit.

  • Failures retry on their own, and stop

    A sweep every half hour, capped — so a permanent problem surfaces as a problem rather than as an infinite retry.

  • Success re-renders the document

    So the reference and its signed code are stamped onto the PDF. And if that render fails, the reference is not lost — the two are not tied together.

  • Cancellation respects the window

    Refused past the statutory deadline rather than attempted and rejected.

Which regime does this cover?

One, fully — the pipeline, the validation and the retry are all built against a single authority's rules. Everything else in the finance module is regime-neutral. This is the clearest example of what we mean by depth in one place rather than a thin layer everywhere.

Can we use our own provider?

Credentials are per entity and encrypted. One provider integration ships today; the structure expects more.

What if we are below the threshold?

Nothing is submitted, and the invoice records that it was below — so when you cross it, the change is visible rather than silent.