Bill of Entry & Import GST Workflow

A design reference for capturing customs-assessed duty and IGST on imported goods and carrying it into the input-tax-credit chain

1. Requirements

1.1 Functional requirements

An overseas supplier’s own invoice carries no GST — duty and integrated tax on an import are assessed by customs at the port of entry, not by the supplier. The system must let the importing company capture that customs assessment as its own document, separate from and linked to the supplier’s invoice.
The Bill of Entry must link to specific line items of an already-submitted purchase invoice that has been explicitly flagged as import-relevant, not to the invoice as a whole, because customs assesses each imported good on its own assessable value.
Goods landing in stages against one purchase invoice line must be supported: several Bills of Entry can be raised against the same purchase invoice over time, each claiming only the quantity still pending against that line.
Tax lines must be computed item-wise, on a base of assessable value plus the customs duty itself (not the purchase invoice’s own net total), using rate and treatment data pulled from each item’s own tax template.
Only import-eligible tax accounts may appear as a tax line on the document — an ordinary intra-state or inter-state split has no meaning at the port of entry, since an import is always treated as if it entered directly into the importing company’s own state.
On submission, the document must post a ledger entry recognizing what is owed to the customs authority — separate from, and never mixed with, whatever is separately owed to the overseas supplier.
The claimed input tax credit and its filing-period assignment must be produced the same way as for a domestic purchase invoice, and the document must be reconcilable against the same government-reported inbound feeds documented separately, using the import-specific categories those feeds carry.
The customs duty captured here must be projectable into stock valuation as a landed cost, and the document must support generating the payment instruction to the customs authority directly.

1.2 Non-functional requirements

No over-claiming against the source line: the quantity claimed by all Bills of Entry raised against one purchase-invoice line can never exceed that line’s own quantity; each unit can be claimed exactly once.
Manually entered tax amounts are checked, not trusted blindly: a tax line whose amount was typed in directly is validated against what the item-wise rate structure would have produced, catching a materially wrong manual entry before it posts.
Single-currency assumption: every account referenced on the document — customs payable, customs expense, and each tax account — is validated to be in the company’s own local currency; there is no foreign-currency posting path for this specific document.

1.3 Constraints

Builds on the shared double-entry posting primitives used by every other submittable transaction in the system, rather than reimplementing ledger-entry construction.
Depends on the source purchase invoice already being submitted and carrying an explicit import-relevant flag; a Bill of Entry cannot be the first document raised for an import.
Generic multi-jurisdiction tax computation, and the mechanics of apportioning any charge across stock items for valuation purposes, are documented separately; this document covers only what is specific to the customs-duty capture step itself.

The Bill of Entry sits between two things the company does not control the shape of — the overseas supplier’s own GST-less invoice, and the government’s own inbound-feed reporting of the import — and one thing it fully controls: the ledger entry that recognizes what is actually owed to customs.

2.2 Pulling lines from the source invoice

Raising a Bill of Entry starts from an explicit “get items from purchase invoice” action rather than free entry:

Select one or more submitted, import-flagged purchase invoices. Only invoices whose category is import-related and that still have a pending claimable quantity on at least one line are offered.
Pull only the pending remainder of each line. Each pulled line carries its own reference back to the exact purchase-invoice line it came from, its assessable value defaulted from that line’s own taxable value, and a starting customs-duty amount of zero.
Default a duty-account IGST tax line if the company has a configured input IGST account and none of the pulled items already carries an equivalent rate, so a fresh document is not left with no tax line at all.
Recompute item-wise tax rates and totals every time an item or a tax line changes — before validation runs, not only on demand — so the totals shown are never stale relative to what will actually be validated and posted.

At submission, the pending-claimable-quantity figure on every referenced purchase-invoice line is recalculated as that line’s own quantity minus the sum of quantities already claimed by every submitted Bill of Entry against it — including the one just submitted. Cancelling a Bill of Entry re-runs the same recalculation, so a cancelled claim’s quantity becomes claimable again immediately.

2.3 Quantity apportionment across multiple Bills of Entry

A draft Bill of Entry is rejected at submission if any line’s claimed quantity exceeds what remains pending on its source line at that moment — the check runs against live state, not against a snapshot taken when the document was drafted, so two Bills of Entry drafted concurrently against the same line cannot both over-claim it.

3. Deep Dive

3.1 Data model

Bill of Entry — the customs-assessment document itself. Carries the customs reference number and date, the company and its registration, the total assessable value and total customs duty across all lines, the total of the tax lines, and the grand total payable to the customs authority. Two accounts are mandatory on every document: a customs-duty-payable account (what is owed) and a customs-duty-expense account (the non-tax portion of the duty itself, as opposed to the IGST/CESS charged on top of it). Carries its own filing-period field and a reconciliation-status field mirroring the one used on an ordinary purchase invoice.

Bill of Entry line — one row per imported good, referencing the exact source purchase-invoice line it was pulled from. Carries the item’s assessable value, the customs duty apportioned to that specific item, a derived taxable value (assessable value plus that item’s own duty share), and per-tax-head rates and amounts (IGST, CESS, and a separate non-ad-valorem CESS rate for goods charged a flat amount rather than a percentage).

Localized taxes-and-charges lines — the tax-line child table the document shares with other places in the system that need a lightweight, item-wise tax table without pulling in the full multi-jurisdiction tax engine (a subcontracting-side transaction is the other consumer). Each line records a charge type (an actual fixed amount, a percentage of net total, or a per-unit-quantity charge), an account head, a rate, a computed amount, and a per-item breakdown of what rate was actually applied to which line — this per-item breakdown is what lets the totals reconcile exactly even when different items on the same document carry different item tax templates.

Item-Wise Tax Controller — the computation that fills in the localized tax lines: for each tax line, it resolves the applicable rate per item from that item’s tax template, multiplies by either the item’s taxable value (for a net-total charge) or its quantity (for a per-unit charge), and sums into the tax line’s total; a manually typed “Actual” amount skips the rate lookup but is still cross-checked against what the item-wise breakdown implies, and a difference of more than a small absolute tolerance is rejected outright rather than silently posted.

3.2 Ledger posting

On submission, three kinds of lines are posted: a debit to the customs-duty-expense account for each line’s customs duty, a debit to each tax line’s own account for its computed amount, and a single credit to the customs-duty-payable account for the sum of everything above. Cancellation reverses the same set of postings and simultaneously clears any reconciliation link a downstream matching pass had already established against the document, resetting its match state back to unlinked — a cancelled Bill of Entry cannot be left dangling as someone else’s matched counterpart.

Only accounts already known to the company’s configured input-tax accounts for IGST and CESS (including the non-ad-valorem CESS variant) are accepted as tax-line accounts; anything else is rejected before it can post. This is the concrete answer to how customs-charged tax reaches the credit chain despite the supplier’s own invoice carrying none: the Bill of Entry is the sole document that ever debits these input accounts for an import, and everything downstream reads from the same accounts an ordinary domestic purchase invoice would have posted to, so nothing downstream needs to know an import was involved at all.

3.3 Downstream consumption

Input tax credit: the Bill of Entry participates in the same claim-period calculation as a purchase invoice — same deferral rule when a match is pending or rejected, same “later of posting period or reported period” default, same statutory cutoff. It is treated as a first-class credit-bearing document, not a side effect of one.
Reconciliation: because import categories carry no usable supplier registration number in the government-reported feeds, the Bill of Entry is matched only through the broader entity-level cascade documented separately, never through the registration-level pass, and using the combined tax total rather than individual tax heads.
Landed cost: a dedicated mapping step locates whichever downstream document actually updated stock for each purchase-invoice line — the purchase invoice itself, or a receipt raised from or against it — and apportions that line’s customs duty onto it as a landed cost charge, so the imported item’s valuation includes what customs actually charged, not just what the supplier billed.
Payment: a mapping step can generate a bank-type journal entry crediting the company’s bank or cash account and debiting the customs-duty-payable account for the document’s total, so settling the customs liability does not require building that entry by hand.

3.4 Error handling

Over-claiming a line’s quantity is rejected at submission with a specific per-item message, using a live recalculation rather than a value cached at draft time.
A tax account outside the permitted IGST/CESS set is rejected before any totals are trusted, so a misconfigured tax line cannot silently post to the wrong account.
A manually entered “Actual” tax amount that disagrees with the item-wise computation by more than a small tolerance is rejected with a suggestion of which charge type would have produced the entered figure, rather than being accepted at face value.
Cancellation is symmetric with submission: it reverses the ledger entry, frees up the claimed quantity on the source line, and clears any reconciliation link, all in the same operation.

4. Scale and Reliability

Load pattern: driven by shipment arrivals rather than a filing calendar, so volume is comparatively steady rather than bursty around a deadline.
Concurrency on the shared source line: the pending-claimable-quantity check reads live state at submission time rather than a cached figure, which correctly rejects a genuine over-claim but does not itself prevent two Bills of Entry against the same line from being validated in the same instant and both passing a check that was true a moment before either committed.
No batch tooling: each Bill of Entry is created, validated, and submitted as an individual document; there is no bulk-import path analogous to the download/retry sweeps used for the government-reported feeds, because there is no external feed to pull here — the document originates entirely from data the company already holds.

5. Trade-off Analysis

Decision	Trade-off
A dedicated document distinct from the purchase invoice, rather than extra fields on the invoice itself	Correctly models that customs assessment is a separate legal event from the supplier’s invoice, and supports staged landing against one invoice line, but doubles the number of documents an operator must track per import and requires an explicit linking step rather than a single self-contained transaction.
A lightweight, per-item tax controller shared with one other transaction type, instead of the full multi-jurisdiction tax engine	Keeps the computation simple for a case that only ever needs IGST/CESS on one assessable-value base, but means any future rule added to the general tax engine (a new charge type, a new rounding behavior) has to be separately ported here if it should also apply to imports.
Live recalculation of pending quantity rather than a reserved/locked quantity at draft time	Simple to reason about for the common sequential case, but leaves a narrow concurrent-draft race unaddressed, as noted in §4.
Reusing the same ITC claim-period and reconciliation logic as an ordinary purchase invoice, rather than a parallel import-specific pipeline	Nothing downstream needs to special-case an import, which is the main win, but it also means any defect or edge case in that shared logic (documented separately) is inherited here unchanged rather than being isolated to imports.

6. What to Revisit as the System Grows

Lock or reserve quantity at draft time rather than only checking it live at submission, once concurrent drafting against the same high-volume import line becomes routine rather than occasional.
Give the per-item tax controller a defined relationship to the general tax engine — either an explicit “these charge types are guaranteed to stay in sync” contract, or a shared computation core — so a future change to one does not have to be remembered and re-applied to the other by hand.
Add batch tooling for high-volume importers raising many Bills of Entry per shipment cycle, if manual one-by-one creation becomes the bottleneck once import volume grows past what a single operator can reasonably key in per day.