VAT-Inclusive vs VAT-Exclusive Calculation in Nepal

A price of NPR 1,130 can mean either NPR 1,130 before VAT or NPR 1,130 with VAT already included. Billing software must make that choice explicit because the formulas, invoice fields, and final amount all change.

Nepal's Inland Revenue Department currently states that the VAT rate is 13%. The Value-Added Tax Act also specifies a flat 13% rate while identifying zero-rated supplies separately. Verify the applicable treatment for the actual goods, services, registration status, and transaction date before issuing an invoice.

This article is technical implementation guidance, not tax or legal advice. Confirm invoice and tax treatment with Nepal's Inland Revenue Department or a qualified adviser.

The amounts and their names

For a taxable sale, keep these values distinct even if the UI initially shows only one price.

Add VAT to a net price

With a rate of 13%, convert a net price to a gross price as follows:

VAT amount = net amount × 0.13
gross amount = net amount + VAT amount

For example, a net amount of NPR 1,000 produces NPR 130 VAT and NPR 1,130 gross.

Extract VAT from an inclusive price

Do not calculate 13% of the inclusive value. The inclusive value is already 113% of the net amount:

net amount = gross amount ÷ 1.13
VAT amount = gross amount − net amount

For NPR 1,130 inclusive, the net amount is NPR 1,000 and the VAT amount is NPR 130. Multiplying 1,130 by 13% would incorrectly return NPR 146.90.

For a configurable percentage rate r, use:

gross = net × (1 + r / 100)
net = gross ÷ (1 + r / 100)
tax = gross − net

Frontend calculation example

JavaScript floating-point arithmetic can produce fractional artifacts. A practical UI can calculate in the smallest supported unit or use a decimal library. This simplified example uses paisa integers and rounds at the documented boundary:

const VAT_BASIS_POINTS = 1_300; // 13.00%
const RATE_SCALE = 10_000;
 
function addVat(netPaisa: number) {
  const vatPaisa = Math.round(
    (netPaisa * VAT_BASIS_POINTS) / RATE_SCALE,
  );
 
  return {
    netPaisa,
    vatPaisa,
    grossPaisa: netPaisa + vatPaisa,
  };
}
 
function extractVat(grossPaisa: number) {
  const netPaisa = Math.round(
    (grossPaisa * RATE_SCALE) /
      (RATE_SCALE + VAT_BASIS_POINTS),
  );
 
  return {
    netPaisa,
    vatPaisa: grossPaisa - netPaisa,
    grossPaisa,
  };
}

VAT_BASIS_POINTS avoids representing the configured rate as an imprecise binary fraction. The subtraction in extractVat guarantees that the displayed net and VAT add back to the entered gross value.

The browser result is only a preview. Send the price mode and source amount to the API, then recalculate on the server; otherwise a caller can alter the submitted VAT amount.

Backend calculation and validation

type PriceMode = "exclusive" | "inclusive";
 
function calculateInvoiceAmount(
  sourcePaisa: number,
  mode: PriceMode,
) {
  if (!Number.isSafeInteger(sourcePaisa) || sourcePaisa < 0) {
    throw new Error("Amount must be a non-negative paisa integer");
  }
 
  return mode === "exclusive"
    ? addVat(sourcePaisa)
    : extractVat(sourcePaisa);
}

Validate the currency, rate, tax category, quantity, discount, and price source on the server too. For large values or currencies with different minor-unit rules, use an audited arbitrary-precision decimal library rather than assuming every amount fits safely in a JavaScript integer.

Choose one rounding policy

Rounding each line and rounding only the invoice total can differ by a few paisa. Neither policy should emerge accidentally from UI formatting.

A typical policy defines:

• the precision used for unit prices and quantities;
• whether discounts apply before tax;
• whether VAT is rounded per line, per tax group, or on the invoice total;
• the rounding mode used for exact half values;
• how adjustments are displayed and posted.

Use the same policy in the browser preview, API, database reports, credit notes, and accounting export. Preserve unrounded calculation inputs where required, but store the issued invoice amounts exactly as presented so a later rate or pricing change cannot rewrite history.

Invoice storage fields

A useful line-item model stores the decision, not just the final total:

CREATE TABLE invoice_line (
  id uuid PRIMARY KEY,
  invoice_id uuid NOT NULL,
  quantity numeric(18, 4) NOT NULL,
  unit_price numeric(18, 4) NOT NULL,
  price_mode text NOT NULL CHECK (price_mode IN ('inclusive', 'exclusive')),
  vat_rate numeric(7, 4) NOT NULL,
  net_amount numeric(18, 2) NOT NULL,
  vat_amount numeric(18, 2) NOT NULL,
  gross_amount numeric(18, 2) NOT NULL,
  CHECK (gross_amount = net_amount + vat_amount)
);

vat_rate is stored on the issued line rather than read from a global setting later. The three resulting amounts support invoice rendering and reconciliation. Add currency, discount, tax classification, override reason, and audit fields according to the application.

Manual price overrides

An override must specify what the operator changed. If they type a new gross amount, derive net and VAT using the inclusive formula. If they type a new net amount, add VAT. Do not silently reinterpret an inclusive override as exclusive.

Record the original value, final value, mode, authorized user, reason, timestamp, and calculation-policy version. Recalculate on the server after authorization. Restrict overrides on finalized invoices; corrections normally need the application's approved credit-note or cancellation workflow.

Common implementation mistakes

• Calculating inclusive × 13% instead of extracting VAT with division by 1.13.
• Trusting net or VAT amounts supplied by the browser.
• Storing only gross amount and trying to infer the historical rate later.
• Mixing per-line and invoice-level rounding between services.
• Applying the standard rate to every item without a verified tax category.
• Using binary floating-point values for posted accounting totals without an explicit rounding boundary.

Use the site's Nepal VAT Calculator to check example inputs, but keep the production backend authoritative.

Verification checklist

• The price input is explicitly inclusive or exclusive.
• The current applicable VAT treatment was verified for the transaction.
• Net, VAT, and gross add up after the documented rounding policy.
• The server recalculates values independently of the browser.
• Issued lines retain their rate, amounts, and override audit data.
• Tests cover zero, fractional quantities, discounts, and rounding boundaries.

References

Documentation checked on 2026-08-12:

• Nepal Inland Revenue Department: VAT FAQ and 13% calculation example
• Nepal Inland Revenue Department: Value-Added Tax Act, section 7