JewelstackJewelstack
A pricing panel listing gold rate, net weight, purity, making charges, stones and tax, beside a gold bangle and a rupee price tag.
Technology

Why generic retail software cannot price what you sell

Generic retail software assumes a price is a number on a product. Jewellery prices are calculations over a rate that changes every morning.

kavin12 Feb 202613 min read

Generic retail software makes an assumption so basic that nobody writing it noticed they were making it: a product has a price, and that price is a number stored against the product.

Change that one assumption and most of the system stops fitting. Not a feature here and there — the catalogue, the cart, the invoice, the reporting and the valuation all rest on it.

Jewellery changes that assumption every morning.

For a jewellery business, the price of a product is rarely just a number saved in a catalogue. It can depend on the live gold rate, net weight, purity, making charges, stone value, wastage and applicable taxes. When the underlying inputs change, the selling price may change with them.

This is where generic retail software begins to struggle. It is designed to sell products with relatively stable prices. Jewellery businesses need systems that can calculate, update and reconcile prices according to the rules of the trade.

The difference is architectural, not cosmetic.

The Assumption Behind Generic Retail Software

Most retail and ecommerce platforms follow a straightforward pricing model: a product has a price, and every transaction uses that price unless someone changes it.

A product record might contain a name, SKU, description, stock quantity and selling price. The cart retrieves the price, the checkout calculates the total, the invoice records the transaction and the reporting system uses the same figure to calculate revenue.

For many retail categories, this model works well.

A T-shirt priced at ₹1,499 does not ordinarily need to be recalculated every morning because the market price of its primary material has changed. A packaged product can generally be sold at its configured price until the business decides to update it.

Jewellery operates differently.

A gold necklace weighing 18 grams can have a different selling price from an otherwise similar necklace weighing 17.5 grams. Two pieces with the same gross weight may have different prices because their purity, stone content, making charges or other pricing components differ.

Even the same piece can have a different metal value tomorrow if the applicable gold rate changes.

The fundamental question, therefore, is not simply, "What is this product's price?"

It is, "Given the current rate, the product's attributes and the business's pricing rules, what should this product cost right now?"

Generic retail software usually treats price as stored data. Jewellery commerce needs price to behave like a calculated business value.

What Jewellery Pricing Actually Requires

Jewellery pricing is not one universal formula. It varies by product category, metal, purity, stone composition, pricing policy and business practice. However, most systems need to account for several distinct inputs.

A gold rate of Rs 6,600 per gram, net weight 10.25 grams, 22K purity, 12% making charges, Rs 18,000 of stones and applicable tax, all feeding into one calculated price for a necklace.
  • Metal rate: The applicable gold, silver or platinum rate, often differentiated by purity or business rules.
  • Net metal weight: The weight used to calculate the metal component, distinguished from gross weight where stones or other materials are present.
  • Purity: The metal's fineness or karatage, which affects the applicable rate and valuation.
  • Making charges: Charges based on weight, percentage, fixed amounts or other pricing rules.
  • Wastage: Where applicable, the wastage percentage or amount defined by the business.
  • Stone value: The value of diamonds, gemstones and other components, which may be calculated or maintained separately.
  • Taxes and adjustments: Applicable GST treatment, discounts and other permitted adjustments.

A simplified illustration of the calculation might look like this:

Metal value = Net metal weight × Applicable metal rate

The final selling price is then calculated using the applicable making charges, wastage, stone value, other components and tax rules.

Consider a hypothetical gold jewellery item with 10 grams of net metal weight. If the applicable metal rate increases from ₹6,500 to ₹6,600 per gram, the metal component rises from ₹65,000 to ₹66,000 before other charges and taxes.

The product has not changed. Its metal component has.

A system built around a permanently stored selling price requires that difference to be managed through manual updates, bulk edits or custom development. A system designed for jewellery can recalculate the relevant component from the updated rate and the product's stored attributes.

That distinction matters across thousands of SKUs, multiple stores and every channel where the product is sold.

Where the Mismatch First Appears

The first problems often emerge in the product catalogue, long before the business notices an incorrect invoice.

Bulk price updates become operational work

When gold rates change, a jewellery retailer may need to update prices across thousands of products. If every SKU stores a fixed selling price, someone must determine which products are affected, calculate their revised prices and publish the changes.

A spreadsheet can perform these calculations, but it introduces another operational dependency. Product data may be exported, modified, reviewed and reimported. During that process, the website, POS and inventory system may temporarily show different prices.

A pricing engine reduces this dependency by storing the underlying product attributes and calculating the selling price from the applicable rate and configured rules.

Product variants become difficult to manage

Jewellery often has closely related variants that differ by size, weight, purity, stone configuration or other attributes.

Treating every variant as an independently priced product creates additional maintenance. A weight change may require a new price, while a purity change may affect the rate calculation itself.

A jewellery-aware catalogue should support these attributes as structured data and apply the appropriate pricing rules to each variant. It should not rely entirely on manually maintained prices for every combination.

Rounding becomes a business rule

Jewellery pricing may involve several calculations, decimal precision requirements and rounding decisions. If the website, POS and invoice module use different calculation sequences, their totals can diverge.

For example, one module may round each component before adding them, while another may calculate the combined amount and round only at the end.

The solution is not merely to add more decimal places. It is to define consistent calculation, precision and rounding rules and apply them across the platform.

The spreadsheet becomes the unofficial pricing engine

Eventually, the operations team may maintain the real pricing logic in a spreadsheet because the software cannot express it adequately.

The spreadsheet becomes responsible for calculations, the product catalogue stores the resulting prices, and employees move data between the two.

At this point, the business has not eliminated manual work. It has moved its most important pricing logic outside the system that is supposed to manage it.

Then It Reaches the Invoice

A product page can look correct while the invoicing model underneath remains unsuitable for jewellery.

An ordinary retail invoice often centres on a product description, quantity, unit price, discount, tax and final amount. Jewellery transactions can require a more detailed representation of the product and its pricing components.

Depending on the transaction and applicable legal requirements, a jewellery invoice may need to capture or display information such as:

  • Product description and item identification.
  • Metal purity and relevant hallmarking information.
  • Gross weight, stone weight and net metal weight, where applicable.
  • Making charges and other separately applicable components.
  • HUID information for applicable hallmarked gold jewellery.
  • Taxable value, applicable GST treatment and tax amounts.
  • Final transaction value and other prescribed invoice particulars.

The exact requirements depend on the transaction, product category and applicable regulations. Businesses should verify their invoicing configuration against current GST and Bureau of Indian Standards requirements rather than assuming that one generic invoice template covers every situation.

The technical problem is structural.

If the system only understands a product name, quantity and fixed selling price, it may have nowhere appropriate to store the weight breakup, purity or other jewellery-specific details. Teams then add custom fields, create separate invoice templates or maintain supplementary records.

A better approach is to treat jewellery attributes and pricing components as part of the transaction model. The invoice should reflect the calculation performed by the pricing engine, preserve the relevant transaction details and support the required statutory fields.

That also makes reconciliation easier. The amount displayed on the website, charged at the POS and recorded on the invoice should follow consistent pricing rules, even when their presentation differs.

Then It Reaches Stock Valuation

Pricing a product for sale and valuing stock are related, but they are not the same operation.

A retailer selling packaged goods may value inventory using an established cost basis, such as purchase cost or another permitted inventory accounting method. The product's retail selling price can change without automatically changing the recorded inventory cost.

Jewellery introduces an additional operational consideration: the market value of the metal held in inventory can change even when no stock has moved.

Suppose a store holds 500 grams of gold-bearing inventory. If the applicable metal rate increases, the indicative metal value of that inventory rises even if no items have been purchased or sold.

A useful jewellery system should distinguish between at least three concepts:

  1. Selling price: The amount calculated for a customer under the applicable pricing rules.
  2. Metal or indicative market value: A value calculated using the relevant metal quantity, purity and rate.
  3. Accounting inventory value: The value recognised under the business's accounting policies and applicable standards.

These values should not be treated as interchangeable.

A daily rate change may update the indicative metal value without automatically changing the accounting carrying value of inventory. Accounting treatment depends on the applicable standards and the business's valuation policy.

When a system cannot represent these distinctions, businesses often resort to separate reports or spreadsheets. That makes it harder to understand metal exposure, compare store-level inventory and reconcile operational valuations with financial records.

Jewellery inventory management needs to support rate-sensitive calculations while preserving the distinction between commercial pricing and accounting valuation.

Then It Reaches Returns and Exchange

Returns and exchanges expose another limitation of a simple retail transaction model.

In conventional ecommerce, a return generally reverses a sale and initiates a refund according to the business's policy. Jewellery transactions can involve several different commercial operations that should not be treated as identical.

Consider three common scenarios.

Returning a recently purchased item

A customer returns a product under the retailer's applicable return policy. The system needs to reference the original transaction, apply the relevant refund rules and update inventory appropriately.

Exchanging old gold for new jewellery

A customer brings old gold and purchases a new item. The retailer assesses the old gold according to its applicable weight, purity, testing results, deductions and buy-back policy. The value of the old gold is then adjusted against the new purchase.

This is not simply a refund. It is a transaction involving an incoming asset, a valuation calculation and a separate sale.

Buying back previously sold jewellery

A customer sells jewellery back to the retailer. The amount paid may depend on the current applicable rate, purity, net metal weight, stone treatment and the retailer's buy-back terms.

The original purchase price does not necessarily determine the current buy-back value.

A system that only supports standard sales, returns and fixed-price refunds will struggle to represent these operations cleanly.

A jewellery-focused platform should maintain the original transaction history while supporting separate valuation rules, exchange adjustments, settlement amounts and appropriate inventory movements.

This becomes particularly important when the same customer exchanges old gold, purchases a new item and pays the remaining balance in a single visit.

The Workarounds and What They Cost

Generic software can often be extended to support parts of jewellery retail. The problem is that extensions are not always equivalent to a coherent jewellery-specific architecture.

The most common workarounds are familiar to growing retailers.

Custom fields: Teams add fields for purity, gross weight, net weight and making charges. This helps capture information, but fields alone do not guarantee that every module knows how to calculate with it.

Spreadsheets: Operations teams calculate prices, reconcile discrepancies and prepare reports outside the core system. This can solve an immediate problem but creates additional review, version-control and data-transfer work.

Bulk imports: Employees repeatedly export and reimport product data to update prices. This introduces opportunities for stale prices, mapping errors and inconsistencies between channels.

Separate systems: The POS, ecommerce platform, inventory application and accounting software each maintain a different representation of the same transaction. Integrations must continually reconcile their differences.

Custom development: Developers build additional pricing logic, exchange workflows and reports around the original software. Over time, updates to the underlying platform may require those extensions to be reviewed or rewritten.

Ongoing maintenance: Someone must own the pricing rules, investigate discrepancies, test changes and ensure that new features do not break existing calculations.

The cost is not limited to development invoices. It also includes staff time, operational delays, reconciliation effort and the risk of selling at an outdated price.

These costs compound as the business grows. A workaround that seems manageable for one store and a few hundred products may become difficult to sustain across multiple branches, thousands of SKUs and several selling channels.

The question is not whether generic software can be customised. It is how much of the jewellery business must be rebuilt around a system that was not designed for it.

What to Require Instead

A jewellery business evaluating software should look beyond feature lists and ask how the platform represents its underlying commercial logic.

A useful starting point is a system in which jewellery attributes, pricing rules, inventory records and transaction calculations work together.

The platform should be able to:

  • Store structured attributes such as purity, gross weight, net weight, stone details and applicable charges.
  • Calculate selling prices from configured rules and the appropriate metal rates.
  • Support rate updates and recalculate affected prices consistently.
  • Apply the same pricing logic across ecommerce, POS and other connected channels.
  • Maintain a clear distinction between selling price, indicative metal value and accounting inventory value.
  • Support jewellery-specific invoicing, returns, exchanges and buy-back workflows.
  • Preserve transaction history for reconciliation, reporting and audit purposes.
  • Apply permissions, validation and approval controls to important rate and pricing changes.

These capabilities should be demonstrated in the actual product, not accepted solely because a vendor says they are possible through customisation.

Three questions to ask in a software demo

1. If the gold rate changes tomorrow morning, what exactly happens to my catalogue?

Ask the vendor to demonstrate a rate update on products with different weights, purities and making-charge rules. Check whether prices are recalculated consistently, how changes reach the website and POS, and whether the system records the relevant update history.

2. Can you complete a jewellery sale and an old-gold exchange without using a spreadsheet or a separate manual calculation?

Ask the vendor to demonstrate the item-level weight breakup, pricing components, invoice details, old-gold valuation and final settlement. A convincing demonstration should show how the transaction is represented in the system, not merely how the final amount appears on screen.

3. Can you show selling price, metal value and accounting inventory value separately?

Ask the vendor to change the applicable metal rate and demonstrate which values update, which remain unchanged and why. The answer should explain how operational valuation and accounting records are handled without treating them as the same number.

These questions reveal more about a platform's suitability than a long list of generic features.

A vendor may be able to add a field or build a custom screen. What matters is whether the pricing model works consistently across the business without creating a growing collection of exceptions.

Frequently Asked Questions

Can generic ecommerce software handle gold rate pricing?

Yes, generic ecommerce software can support gold rate pricing through custom development, integrations or external pricing engines. However, the implementation must account for product weight, purity, making charges, stone value, applicable taxes and consistent calculations across the catalogue, cart, checkout and POS. The key question is whether jewellery pricing is supported by the underlying architecture or maintained through additional workarounds.

What must appear on a jewellery invoice in India?

A jewellery invoice in India must comply with the applicable GST invoicing requirements and any relevant product-specific legal requirements. Depending on the transaction and product, relevant details may include the product description, taxable value, GST particulars, metal purity, weight breakup, making charges and HUID information for applicable hallmarked gold jewellery. Businesses should verify the current requirements for their specific transactions rather than assuming every detail is universally mandatory.

Why do jewellery businesses end up running spreadsheets alongside their software?

Jewellery businesses often use spreadsheets when their software cannot adequately represent rate-dependent pricing, weight and purity attributes, inventory valuation or exchange calculations. Spreadsheets provide flexibility, but they can create duplicate records, manual reconciliation and inconsistencies between ecommerce, POS and inventory systems. A properly designed jewellery platform can reduce this dependence by making the relevant rules part of the core workflow.

How is jewellery stock valuation different from ordinary retail?

Jewellery stock valuation can involve monitoring metal quantities, purity and changes in applicable market rates, while also accounting for stones and other product components. A change in the metal rate may affect indicative market value even when no stock has moved. However, indicative metal value, selling price and accounting inventory value are distinct measures and should be managed according to the business's pricing rules and applicable accounting policies.

Keep reading

Bring your rate, your catalogue and your worst spreadsheet.

Book a walkthrough +91 7703 929 790[email protected]