---
title: "NBR Mushak 6.3 Challan: What It Is and How to Comply"
date: 2026-06-17
updated: 2026-08-29
lang: en
tags: ["compliance", "vat-nbr", "bangladesh"]
summary: "An evidence-first Mushak 6.3 workflow for restaurant invoice configuration, sequence control, correction, reconciliation and retrieval—without a universal rate claim."
canonical: https://rosuii.com/blog/nbr-mushak-6-3-challan-guide
author: "Rosuii Team"
---

# NBR Mushak 6.3 Challan: What It Is and How to Comply

An evidence-first Mushak 6.3 workflow for restaurant invoice configuration, sequence control, correction, reconciliation and retrieval—without a universal rate claim.

**Last verified: 2026-08-29**

## Verify current NBR requirements before configuration

VAT forms, rates, registration status and invoice requirements can change and can depend on the registered person and transaction. Use current National Board of Revenue guidance, the restaurant's applicable registration or enlistment records and qualified VAT advice. This guide must not be treated as a determination that one rate or form configuration applies to every restaurant.

Keep the official source URL or document, effective date, reviewer and approved configuration together. Do not copy another restaurant's BIN, invoice format or tax treatment.

The NBR rules index currently lists an authenticated text dated in 2025, and the current VAT SRO index lists 2026 amendments to the 2016 rules. That is evidence that a saved template must be checked against amendments; it is not a conclusion about the restaurant's exact treatment.

**Sources for this section:** [NBR — VAT and Supplementary Duty Act index](https://nbr.gov.bd/regulations/acts/vat-acts/ban) · [NBR — VAT and Supplementary Duty Rules index](https://nbr.gov.bd/regulations/rules/vat-rules) · [NBR — Current VAT SRO index](https://nbr.gov.bd/regulations/sros/vat-sros/21/eng)

## Invoice data control matrix

The visible print and stored transaction should derive from the same finalized order. Reprinting should identify the same invoice rather than create a new sale or sequence number.

| Data group | Source of truth | Control |
| --- | --- | --- |
| Supplier identity | Approved registration/business record | Restricted changes |
| BIN or relevant identifier | Authority-issued record | Exact value |
| Invoice number | Controlled sequence | Unique and traceable |
| Date/time | Authoritative transaction event | No casual backdating |
| Items/amounts | Final order lines | Preserve correction history |
| VAT/tax fields | Approved current configuration | Effective dating |
| Buyer data where required | Transaction/customer input | Minimum necessary data |

## Configuration and change workflow

Restrict tax and invoice configuration. An emergency cashier role should not be able to change a rate to resolve a customer disagreement. Use the formal correction workflow and preserve original documents according to applicable requirements.

- Qualified owner confirms applicable treatment
- Effective date and branch scope recorded
- Test item and receipt prepared
- Rounding and discount order reviewed
- Void, return and correction tested
- Sequential numbering and duplicate prevention tested
- Digital and printed copy compared
- Prior configuration archived
- First live period reconciled

## Daily and period reconciliation

Reconcile issued invoice sequence, finalized sales, cancellations, returns, payment states and any approved adjustments. Investigate gaps or duplicates from source events instead of manufacturing a replacement document. Keep reports that allow a reviewer to trace summary values to individual invoices.

At period close, lock the reviewed dataset and document late corrections. The POS can calculate and retain configured fields, but it does not decide the restaurant's legal VAT obligation or file returns without appropriate reviewed workflow.

## Safe record retention and retrieval

Protect invoice and registration records with role-based access, backup and tested export. Avoid putting credentials or unnecessary customer personal data in support files. Store authoritative templates and configuration approvals separately from generated customer invoices.

Run a retrieval test using a selected invoice number and period: locate the order, item lines, configured rule, payment, correction and report inclusion. Seek NBR or qualified professional guidance for retention, format and submission obligations current to the restaurant.

Before a software migration, export the full invoice sequence, item and tax fields, cancellation or correction links, customer copy where legitimately retained, and configuration evidence in a reproducible format. Test selected early, middle and recent documents. Map legacy identifiers to the new system without renumbering old invoices. Keep the previous records read-only under the approved retention process, and document which system answers historical queries. A migration checksum or row total alone cannot prove that tax fields and correction relationships survived.

## Create an applicability and evidence file

Do not configure from a competitor receipt, an old blog or a seller's generic demo. Preserve the source document and the restaurant-specific decision that maps it into the system. If the restaurant's exact position is uncertain, mark it unresolved and obtain qualified or NBR guidance before live issuance.

Keep legal interpretation out of cashier discretion. The cashier can select an approved transaction type but should not change a VAT rate, BIN, tax basis or invoice series to settle a customer disagreement.

| Question | Evidence | Owner |
| --- | --- | --- |
| Registered or enlisted status | Authority-issued current record | Owner/VAT adviser |
| Branch or unit scope | Approved registration mapping | Finance/operations |
| Supply and invoice context | Current law/rules/advice | Qualified reviewer |
| Rate and tax basis | Current applicable source | VAT owner |
| Form/device/process | Current approved requirement | VAT/technology owner |
| Effective date | Gazette/source and review | Approver |
| POS configuration | Signed configuration sheet | Restricted admin |
| Retest | Receipt and correction evidence | Reviewer |

## Separate order, invoice and payment states

An order can be open, finalized, cancelled or corrected; an invoice can be unissued, issued, reprinted or handled through the applicable correction process; payment can be pending, paid, failed, refunded or reconciled. Do not collapse those states into one completed flag.

Generate or recognize the invoice event only at the approved point in the restaurant workflow. A kitchen ticket, provisional bill or payment attempt is not automatically the final tax invoice. Define the current process with qualified review and test dine-in, takeaway, delivery and business-customer scenarios actually used.

Reprint should normally refer to the same stored invoice event rather than create a second sale or silently consume a new sequence. The exact reprint marking and correction treatment must follow the applicable current requirement.

## Test value, discount and rounding logic

Use exact decimal and rounding rules approved for the restaurant; do not copy a formula from an old receipt. Compare the stored transaction, displayed bill, printed or digital customer document and period report. A one-line total match does not prove line-level tax fields are correct.

Changes need an effective date and regression test. Do not recalculate historical issued documents under a new configuration unless the authorised legal/accounting process specifically requires a visible adjustment.

| Case | Test | Evidence |
| --- | --- | --- |
| Single item | Approved price and tax basis | Order vs invoice |
| Multiple quantities | Line and total extension | Recalculation |
| Item discount | Order of calculation | Approved rule |
| Bill discount | Allocation to lines/tax | Configuration note |
| Service charge | Treatment if applicable | Qualified approval |
| Supplementary duty | Only where applicable | Current source |
| Rounding | Line vs document outcome | Defined precision |
| Refund/correction | Linked original and effect | Audit trail |

## Sequence, concurrency and outage controls

Use a controlled, unique, traceable invoice identifier under the restaurant's approved design. Two counters, devices or offline queues must not issue the same identifier. Test concurrent finalization, retry after a timeout and duplicate print/request behavior.

A missing number is an exception to investigate, not a reason to manufacture a sale. Preserve reservation, failed transaction or cancellation evidence where the applicable process requires it. Never backdate or renumber documents merely to make a report visually continuous.

Document what happens during internet, server, printer or fiscal-device interruption. Generic POS offline billing support does not prove the exact VAT invoice or EFD/SDC workflow operates offline. Use only the current approved fallback and reconcile the outage window.

## EFD, SDC or approved-device boundary

Some establishments or processes may be subject to current NBR device or system requirements. Determine whether and how the restaurant, branch and transaction are covered from current official instructions and qualified advice. This guide does not declare every restaurant covered or exempt.

A normal thermal receipt printer or browser POS is not automatically an approved fiscal device. Verify device identity, registration/configuration, connectivity, receipt output, failure process and who may service it. Keep vendor marketing separate from authority approval evidence.

If a third-party device or fiscal system is integrated, test stable transaction IDs, duplicate prevention, rejection, retry, correction and daily reconciliation. Do not expose credentials or let support alter tax configuration without authorised, logged access.

## Daily exception and period-close pack

Trace a sample from order lines through the customer document, payment and summary. Period totals should be reproducible from locked details. Do not force a match by editing sales or creating replacement documents without the authorised process.

The POS may calculate configured values and retain records; it does not determine legal registration, rate, filing or correction obligations. Qualified review and the restaurant's controls remain necessary.

- Opening approved configuration/version
- Issued identifier range and count
- Finalized sales and invoice mapping
- Cancelled, returned and corrected documents
- Duplicate, gap, failed and pending events
- Cash and digital payment states
- Device/connectivity incident window
- Late or post-lock adjustment
- Reviewer, unresolved owner and close time

## Access, migration and retrieval acceptance

Limit registration identity, tax rule, invoice sequence, locked-document correction and bulk export to authorised roles. Log view/export where appropriate and every configuration change, approval and effective date. Remove former staff and vendor support sessions.

Before migration, export invoice identifiers, dates, item/amount/tax fields, payment links, cancellations/corrections and configuration versions in a reproducible format. Test early, middle and recent records; a row count alone does not prove relationships survived.

Run a retrieval drill: given one invoice identifier and period, locate the customer document, source order, approved rule version, payment, correction, report inclusion and responsible actors. Record time and gaps as process evidence, not a public performance claim.

## Related guides

- [Compare restaurant management software](https://rosuii.com/compare)

## Sources checked

- [NBR — VAT and Supplementary Duty Act index](https://nbr.gov.bd/regulations/acts/vat-acts/ban)
- [NBR — VAT and Supplementary Duty Rules index](https://nbr.gov.bd/regulations/rules/vat-rules)
- [NBR — Current VAT SRO index](https://nbr.gov.bd/regulations/sros/vat-sros/21/eng)

[Start using Rosuii for free](https://rosuii.com/register)

## FAQ

### What is Mushak 6.3?

It is an NBR VAT invoice form/context; the current applicability and required fields must be verified for the registered business and transaction.

### Can POS software make a restaurant VAT compliant automatically?

No. It can apply approved configuration and preserve records, while legal treatment, procedures, review and filing remain the business's responsibility.

### What should happen to a cancelled VAT invoice?

Use the current applicable correction or cancellation process and preserve the original identifier, reason, user and linked replacement where required.

---
Canonical: https://rosuii.com/blog/nbr-mushak-6-3-challan-guide
Machine-readable site overview: https://rosuii.com/llms.txt