Skip to content
RosuiiRosuii

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.

By 7 min read
Share
NBR Mushak 6.3 Challan: What It Is and How to Comply

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 · NBR — VAT and Supplementary Duty Rules index · NBR — Current VAT SRO index

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 groupSource of truthControl
Supplier identityApproved registration/business recordRestricted changes
BIN or relevant identifierAuthority-issued recordExact value
Invoice numberControlled sequenceUnique and traceable
Date/timeAuthoritative transaction eventNo casual backdating
Items/amountsFinal order linesPreserve correction history
VAT/tax fieldsApproved current configurationEffective dating
Buyer data where requiredTransaction/customer inputMinimum 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.

QuestionEvidenceOwner
Registered or enlisted statusAuthority-issued current recordOwner/VAT adviser
Branch or unit scopeApproved registration mappingFinance/operations
Supply and invoice contextCurrent law/rules/adviceQualified reviewer
Rate and tax basisCurrent applicable sourceVAT owner
Form/device/processCurrent approved requirementVAT/technology owner
Effective dateGazette/source and reviewApprover
POS configurationSigned configuration sheetRestricted admin
RetestReceipt and correction evidenceReviewer

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.

CaseTestEvidence
Single itemApproved price and tax basisOrder vs invoice
Multiple quantitiesLine and total extensionRecalculation
Item discountOrder of calculationApproved rule
Bill discountAllocation to lines/taxConfiguration note
Service chargeTreatment if applicableQualified approval
Supplementary dutyOnly where applicableCurrent source
RoundingLine vs document outcomeDefined precision
Refund/correctionLinked original and effectAudit 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

Sources checked

Start using Rosuii for free

Updated:

Frequently asked questions

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.

Run your restaurant on Rosuii

POS, menu, inventory, payroll and more — built for Bangladeshi restaurants.

Start free
Loyverse Alternative: When Your Cafe Outgrows Free POS

Loyverse Alternative: When Your Cafe Outgrows Free POS

Loyverse gives small cafes a genuinely free POS, and that is worth respecting. But once you add online ordering, bKash payments, payroll and serious inventory, you outgrow it. Here is when a Loyverse alternative makes sense.

By Jun 23, 20267 min read