ERP Product Master and Price List System Guide

A product master is the controlled source of identity and commercial defaults for every item a business buys, stores, sells, invoices, imports, or reports. When product names, units, HSN codes, tax rates, barcodes, and prices are maintained independently in spreadsheets and user memory, duplicate records and reporting mismatches become inevitable.

This guide explains how Indian traders, wholesalers, retailers, distributors, suppliers, and small manufacturers can design a practical product master and price list system. It covers identifiers, units, GST fields, variants, customer price lists, effective dates, imports, approvals, audit history, multi-company copying, and rollout acceptance.

Author and Editorial Review

By Tushar C. (Founder, VASUYASHII). Editorial review covers master-data governance, billing and inventory consistency, price controls, imports, auditability, multi-company boundaries, and ERP-lite implementation scope.

Quick Answer

A reliable product master needs a stable product ID, buyer-friendly name, SKU or code, barcode where used, category, HSN or SAC, unit, GST rate, purchase and sale reference prices, stock settings, status, and audit history. The exact fields vary by business.

A price list should not overwrite transaction history. Store the customer or channel context, currency, unit, amount, tax basis, effective start and end date, priority, minimum quantity if relevant, approval, and version. At invoice time, the system should resolve the applicable price and preserve the selected value on the transaction.

Why Product Masters Fail

Typical failures include:

• the same item entered under several spellings
• supplier codes used as internal identity
• piece, pcs, unit, box, and carton mixed freely
• one barcode assigned to multiple items
• HSN or GST copied without verification
• current sale price treated as historical truth
• inactive products deleted despite old transactions
• imports creating duplicates on every upload
• each branch maintaining a separate uncontrolled sheet
• one company seeing or changing another company's data

These issues affect purchasing, stock, billing, returns, margins, tax reports, ecommerce catalogs, and analytics. Cleaning the master is therefore an operating project, not a cosmetic database task.

Product Identity Model

Separate technical identity from the labels people see.

Do not use a name as the database key. Names change for clarity; the underlying product identity and transaction relationships must remain stable.

Product Type and Variant Decisions

Different businesses need different record shapes:

• simple stocked item
• non-stock service
• style with colour or size variants
• bundle or kit
• item with batch or expiry tracking
• serialised item
• alternate-unit product
• raw material and finished good, if manufacturing is in scope

Do not enable every type by default. Each adds validation, movement, return, and reporting rules. A hardware shop may need piece, box, metre, and brand variants; a garment shop needs colour-size combinations; a stationery supplier may need pack quantities; a service business may need SAC without stock.

For apparel-specific modelling, use the garment inventory guide.

Recommended Core Fields

Identification

• name
• SKU or internal code
• barcode
• category and subcategory
• brand
• description
• active or inactive state

Tax and unit

• HSN or SAC
• GST rate
• base unit
• alternate units and conversion, if supported
• tax-inclusive or exclusive price policy

Commercial defaults

• reference purchase price
• reference sale price
• MRP where genuinely applicable
• minimum sale price or approval threshold
• standard discount policy

Inventory

• stock-tracked flag
• opening quantity through an opening transaction, not a casual field
• low-stock threshold
• preferred supplier
• reorder quantity or lead time where maintained
• location settings

Operations

• images or documents
• created and updated user/time
• approval status
• change reason for protected fields

Keep unknown values empty rather than entering zero or arbitrary text that later appears valid.

HSN, SAC, GST and Effective Changes

The system can store tax configuration, but the business must verify the correct classification and rate with its adviser. Restrict who can change these values.

When a rate changes, use an effective-date process rather than editing historical invoices. Future transactions should use the applicable configuration; posted transactions should retain the original HSN, rate, taxable value, and tax amounts used at that time.

Test intra-state and inter-state billing, inclusive and exclusive pricing where supported, exempt or zero-rated scenarios relevant to the business, returns, discounts, freight, and rounding. Product-master correctness is necessary but invoice calculation still needs separate acceptance.

Units and Pack Conversions

Choose one base unit for stock. Alternate units convert to it using controlled rules.

Example:

• base stock unit: piece
• 1 box = 12 pieces
• 1 carton = 10 boxes = 120 pieces

The system may allow purchase in cartons and sale in boxes or pieces while storing movement in the base unit. Conversion changes are dangerous after transactions exist. If a supplier changes pack size, create an effective rule or new sellable configuration rather than rewriting history blindly.

Define rounding for divisible units such as metre, kilogram, or litre. Do not allow fractional pieces unless the product can genuinely be split.

Barcode Governance

Decide whether the business uses manufacturer barcodes, internal labels, or both. Validate uniqueness before save and import.

Controls include:

• barcode format and length
• variant-level assignment
• duplicate detection
• label template and printer compatibility
• reprint permissions
• inactive-product behaviour
• scan fallback when a label is damaged
• no reassignment without approved migration

Barcode is a lookup method, not product identity itself. Preserve internal IDs even when labels change. Review the barcode inventory guide before buying devices.

Price List Data Model

A single sale_price field is insufficient when rates vary. A practical price-list record can include:

• list name and business purpose
• company or branch scope
• customer, customer group, channel or territory
• product or category
• unit
• currency
• amount or discount rule
• tax inclusion
• minimum quantity or quantity slab
• effective start and end
• priority when multiple rules match
• active, draft or approved status
• created, approved and changed by

Examples include retail, dealer, wholesale, institutional, online, branch-specific, and contract prices. Use only the dimensions the business can maintain.

Price Resolution Rule

Write the precedence before development. One example is:

1. valid customer-contract price
2. valid customer-group and product price
3. valid channel or territory price
4. default product sale price
5. controlled manual override with permission

If two valid records have the same priority, the system should flag a conflict rather than silently choose whichever row loads first.

At quotation or invoice time, record the source price list, original amount, applied discount or override, final unit rate, tax basis, and approval where required. Later price-list edits must not change the posted transaction.

Quantity Slabs and Schemes

Quantity-based prices might be:

• 1-9 units: standard rate
• 10-49 units: dealer rate
• 50 or more: bulk rate

Define whether quantity is per line, product family, order, month, or agreement. A buy-X-get-Y scheme is not always the same as a lower unit rate; it may affect stock, invoice presentation, tax, returns, and margin differently.

Keep scheme logic separate when the business needs eligibility, benefit items, dates, customer groups, stacking, and reversal. See the distributor billing guide for transaction-level controls.

Price Updates and Approval

A bulk update should use a preview and approval flow:

1. upload or prepare proposed changes
2. validate products, units, duplicates, dates and amounts
3. show old and new values
4. identify overlapping rules
5. require approval for protected lists
6. activate at the effective date
7. preserve the prior version
8. produce an exception report

Do not overwrite a complete price list from an unchecked spreadsheet. A missing row may unintentionally remove a valid price. Decide whether an import is append, update, replace, or deactivate and show the impact before commit.

Import and Deduplication

Prepare an import contract with required columns, formats, allowed values, and matching rules. Match existing records by stable ID, approved SKU, or barcode, not fuzzy name alone.

The import should report:

• rows accepted
• rows rejected with reason
• potential duplicates
• unknown units, categories, tax codes or suppliers
• conflicting barcodes
• invalid or overlapping price dates
• products to create, update, deactivate or leave unchanged

Run a dry preview before actual import and keep the source file and result. For a large migration, reconcile record counts, sample transactions, inventory totals, and price output.

Inactive, Archived and Deleted Products

Products with transaction history should normally become inactive, not disappear. Inactive products remain visible in old invoices and reports but cannot be selected for new transactions unless reactivated.

Use permanent deletion only for authorised duplicate or test data under strict conditions. If two duplicate products both have transactions, merging requires a controlled migration and audit record; changing the label of one does not combine stock history.

Multi-Company and Copy Masters

One user may manage several firms. Each company can have different GST details, numbering, prices, stock, customers, purchases, and invoices. Product masters may be copied for convenience, but transactions and balances must remain company-specific.

A Copy Masters feature should define:

• source and destination company
• product fields eligible for copy
• duplicate matching rule
• whether price, tax and barcode are copied
• preview and conflict handling
• permission and audit record
• no copying of stock quantity or transaction history by default

Backend company-scoped permission checks are mandatory. Hiding another company in the dropdown is not enough.

Audit Trail and Protected Changes

Record who changed protected fields, when, old value, new value, and reason. High-risk fields include SKU, barcode, unit conversion, GST, purchase cost, sale price, active state, and company scope.

Useful controls:

• role-based create and edit access
• approval for bulk changes
• reason for manual price override
• export permissions
• duplicate warning
• immutable posted transaction values
• restore of accidental master changes where safe

Review price and tax changes by user and period. Repeated overrides may indicate a missing price rule or training issue.

Reports and Data-Quality Dashboard

The master itself needs operational reports:

• products missing SKU, unit, HSN/SAC, GST or category
• duplicate names, SKUs or barcodes
• inactive products with stock
• products without recent movement
• overlapping or expiring price lists
• invoices using manual price override
• negative or zero margins under defined calculation
• recent protected-field changes
• import errors awaiting resolution
• products copied across companies with conflicts

Do not use a single "data quality score" without showing the underlying exceptions and owner.

Cost Drivers

Product master and price list system cost depends on:

• number of products, variants and companies
• units and pack conversions
• barcode and label workflow
• HSN, GST and pricing complexity
• customer or channel-specific lists
• quantity slabs and scheme rules
• import volume and data quality
• approvals and audit depth
• inventory, billing and purchase integration
• ecommerce, catalog or marketplace sync
• user roles, branches and offline needs
• reports, backups, training and support

A clean configurable master can be implemented faster than a custom rule engine. Most delays come from unresolved business definitions and poor source data rather than screen coding.

Phased Implementation

Phase 1: Data dictionary

Define product types, identifiers, naming, categories, units, tax fields, prices, protected changes, and ownership.

Phase 2: Pilot category

Clean and import one representative category. Test create, update, barcode, price resolution, invoice selection, return, and reporting.

Phase 3: Migration

Dry-run remaining products, resolve duplicates, import approved data, capture opening stock through controlled records, and reconcile.

Phase 4: Price lists and integration

Add customer tiers, effective dates, approvals, catalog sync, or automation after base product identity is stable.

Acceptance Checklist

• [ ] Every product has a stable internal identity.
• [ ] SKU and barcode uniqueness rules are enforced.
• [ ] Naming, category and unit standards are documented.
• [ ] HSN, GST and tax ownership are verified.
• [ ] Alternate-unit conversions pass transaction tests.
• [ ] Historical invoices retain original values.
• [ ] Price-list precedence and conflicts are deterministic.
• [ ] Effective dates prevent accidental retrospective changes.
• [ ] Bulk imports support dry run and error reporting.
• [ ] Inactive products remain in historical reports.
• [ ] Protected changes have permission and audit history.
• [ ] Multi-company copying excludes transactions and stock.
• [ ] Company-level access has negative tests.
• [ ] Backup and restore are tested.

Common Mistakes

• Using product name as the permanent identifier.
• Creating new products instead of aliases or cleanup.
• Changing pack conversion after transactions exist.
• Reassigning a barcode to another variant.
• Overwriting old invoices through master edits.
• Loading every price into one sale-price field.
• Ignoring overlapping effective dates.
• Replacing price lists without a preview.
• Deleting inactive products with history.
• Copying stock and invoices when only masters were intended.
• Giving every operator price and tax edit access.

Current VASUYASHII Business Suite Positioning

VASUYASHII Business Suite is positioned as GST billing, inventory and business management ERP-lite for Indian SMEs. Its product direction includes company-scoped products with SKU or barcode, HSN/SAC, units, GST, purchase and sale prices, stock visibility, imports and exports, invoices, purchases, returns, payments, reports, multi-company support, and Copy Masters for products, clients, and vendors.

Complex price engines, manufacturing BOM, full accounting, marketplace sync, advanced batch costing, and statutory integrations should not be assumed without separate confirmation.

For a scope review, contact VASUYASHII with sample product and price sheets, unit conversions, customer groups, effective-date rules, companies, and current duplicate problems. Use software development services for verified custom requirements.

FAQs

Is SKU the same as barcode?

Not necessarily. SKU is the business's product identifier; barcode is a scannable identifier. They may match, but both need defined uniqueness and lifecycle rules.

Should each colour and size be a separate product?

Use a parent style with separately stocked variants when colour and size affect identification, stock, barcode, price, or sale. The exact model depends on the merchandise.

Can one product have several prices?

Yes. Store distinct lists or rules by customer, group, channel, territory, unit, quantity, or date. Define precedence and preserve the applied price on each transaction.

What happens when GST changes?

Use a verified effective-date process for future transactions. Posted invoices should retain the original tax inputs. The business remains responsible for correct classification and statutory treatment.

Can masters be copied to another company?

Yes, with a preview, duplicate rules, field selection, permissions, and audit trail. Stock, invoices, purchases, payments, and balances should remain company-specific unless a separate migration is explicitly approved.

How should duplicate products be merged?

First identify the canonical product and all related stock and transactions. Use a controlled migration with reconciliation and audit history. Do not simply delete one record or rename both.

Final Decision

Treat product and price data as governed business records. Stable identity, explicit units, effective prices, controlled imports, and auditability are the foundation for trustworthy billing, stock, catalog, and reports.

• Try the Business Suite live demo
• Discuss product-master implementation
• Review custom software services