Mushak 6.3: when you must issue one, and what goes wrong

If your business is VAT-registered in Bangladesh, the Mushak 6.3 is the document you issue when you make a taxable supply. It is not an optional internal record and it is not the same thing as your commercial invoice, though in practice most businesses combine them. Getting it wrong is one of the more common reasons a VAT rebate claim gets rejected further down the chain.

What a 6.3 actually is

Under the VAT and Supplementary Duty Act 2012, a registered person making a taxable supply must issue a VAT challan to the recipient at the time of supply. That challan is form Mushak 6.3. It is the document that lets your customer claim input VAT on the purchase — which is why customers who are themselves registered will chase you for it.

The important consequence: your 6.3 is someone else's rebate evidence. An error you make does not only affect you. It affects your customer's claim, and they will notice.

When it must be issued

The challan is issued at the time of supply. For goods, that is generally when they are delivered or made available; for services, when the service is rendered. Issuing it late, or issuing it only when the customer asks weeks afterwards, creates a mismatch between the period the supply belongs to and the period the document is dated — and that mismatch is exactly what reconciliation catches.

What it must contain

The prescribed form sets the content, but the fields that most often cause problems are these:

• Your BIN and the recipient's BIN — a missing or wrong recipient BIN is the single most common defect, and it invalidates the customer's claim
• A sequential challan number that does not repeat or skip within the period
• Description, quantity and unit of the goods or services, in enough detail to identify what was supplied
• Value excluding VAT, the VAT rate applied, and the VAT amount stated separately
• Supplementary duty where it applies, shown separately from VAT
• The date of supply, which is the date that drives which return period it falls into

The four mistakes worth designing against

1. Retyping the invoice into a separate VAT register

Where the commercial invoice lives in one system and the 6.3 is typed into another, the two drift. A discount applied after the invoice was raised, a line item corrected, a quantity amended on despatch — any of these can be captured in one place and not the other. When the VAT return is built from the register and the accounts are built from the invoice, the two will not agree, and reconciling them at year end is miserable work.

The fix is structural rather than procedural: the challan should be generated from the invoice record, so there is only one set of numbers to be wrong.

2. Treating VAT-inclusive prices as VAT-exclusive

Retail and many B2C sales are quoted inclusive of VAT. The challan must still show the value and the VAT separately, which means backing the tax out of the gross figure rather than adding it on top. Doing this by hand across a month of transactions produces rounding drift that shows up as a small, persistent, unexplainable difference on the return.

3. Ignoring the numbering sequence

Challan numbers should run in an unbroken sequence. Gaps invite the question of what was in the gap. If a challan is cancelled, the number should remain in the sequence marked as cancelled, not be reused and not silently disappear. Systems that let a user delete a document outright rather than void it create exactly this problem.

4. Not linking credit notes back to the original supply

When a sale is returned or a price is corrected, the adjustment needs to reference the original challan. An unlinked credit note reduces your output VAT without anything tying it to the supply it reverses, and that is difficult to defend.

How to check your own position

Three reconciliations, run monthly, will surface most problems before NBR does:

1. 1Total output VAT on issued 6.3 challans against total output VAT in your sales ledger for the same period. These should be identical, not close.
2. 2Challan number sequence for the period — confirm no gaps, no duplicates, and that every cancelled number is accounted for.
3. 3Recipient BIN completeness on every challan issued to a registered customer. Any blank is a rebate your customer cannot claim.

None of this is difficult when the challan is a by-product of recording the sale. It becomes difficult when it is a separate clerical task performed after the fact, which is the situation most spreadsheet-based businesses are actually in.