Avoid price discrepancies in WooCommerce: From product price to accounting
Price discrepancies often arise at the intersection of product data, discount rules, VAT, shipping, payment and the accounting system. Here is how to establish a controlled pricing flow throughout the online store.
Category: WooCommerce
A customer sees one price on the product page, another in the cart and a third amount on the invoice. The differences do not need to be large before they cause problems. A discrepancy of just a few kroner can trigger customer service requests, manual corrections, accounting errors and uncertainty about which figures are actually correct.
In a professional WooCommerce store, price is not just a field on the product. The final amount is shaped by product variations, customer type, discount rules, VAT, shipping, rounding, payment solutions and integrations. Prices should therefore be treated as a continuous process from the product catalogue to bookkeeping and refunds.
Start by defining which systems are authoritative
The first question is not which price should be displayed, but which system has the authority to determine it. In a simple store, WooCommerce may be the primary source for product prices. In a more complex business, prices may come from an ERP system, a product information system or a customer-specific price list.
Problems arise when multiple systems are allowed to change the same value. One integration imports the regular price overnight, while an editor enters a promotional price directly in WooCommerce. The next synchronisation overwrites the promotion or sends the local change back to the accounting system.
Therefore, create a simple overview of responsibilities:
- Which system owns the regular product price?
- Where are promotional prices and discounts created?
- Which system determines the VAT code?
- Where are customer-specific prices maintained?
- Who determines the shipping price and any fees?
- Which amounts should be transferred to payment, inventory and accounting?
Each field should have one clearly defined primary source. Other systems may read and use the value, but should not overwrite it without a defined rule.
Distinguish between product price and calculated order amount
The product price is only the starting point. The order amount is calculated based on the specific cart and the customer's situation. It may be affected by quantity, variation, customer account, discount code, delivery address and selected shipping method.
This distinction is important when planning integrations. An external system should not automatically try to recreate the order by retrieving the current product price. The price may have changed after the customer placed the order. The order must be treated as a historical document containing the prices, discounts and charges that actually applied at the time of purchase.
The integration should therefore transfer the actual amounts on the order lines, not just the product number and quantity. It must also handle discounts, shipping, VAT and any fees in a way the receiving system understands.
Make variations clear before creating pricing rules
Variable products are a common source of pricing errors. Size, material, pack size or subscription type can affect price, weight, inventory status and tax. If variations are incomplete or used inconsistently, it becomes difficult to verify the final amount.
Avoid using free-text fields or add-ons for properties that actually define a separate salable product. If an option has its own price, inventory or item number, it should normally be identifiable as a clear variation or order line.
In particular, check that:
- each salable variation has the correct item number
- prices are set at the correct level
- default selections do not hide more expensive alternatives
- the price display explains whether it shows a from price or the selected variation
- the integration recognises the variation's item number
A well-structured product catalogue makes checkout, picking, customer service and reporting more reliable.
Determine the order for discounts, VAT and shipping
Many discrepancies are not caused by incorrect figures, but by different calculation rules. Two systems can use the same prices and still arrive at different totals if they calculate discounts, VAT or rounding in a different order.
Clarify, among other things, whether discounts should be calculated before or after VAT, whether shipping should be discounted, and how fixed discounts should be allocated across order lines. The same applies to VAT on shipping and fees. The rules must fit the business's sales processes and be consistent across the online store, payment system and accounting system.
Rounding must also be tested. One system may round each order line, while another rounds the total. The difference becomes particularly visible with many order lines, low unit prices or the allocation of a fixed discount.
Do not try to conceal such discrepancies by adding random adjustment lines. Instead, document the calculation method and ensure that the integration sends sufficiently detailed amounts.
Let checkout show the complete calculation
Checkout should not be where the customer discovers VAT, shipping or a fee for the first time. Pricing throughout the purchasing journey should be consistent and explain what is included.
Test the transition between the product page, cart and checkout. The customer should be able to understand:
- unit price and quantity
- which variation is selected
- which discount has been applied
- whether prices are shown including or excluding VAT
- shipping costs and any terms for free shipping
- final amount before the order is submitted
For business customers, it may be necessary to show prices excluding VAT, while private customers expect total prices. If the store serves both groups, the customer type and display rules must be tested thoroughly. It is not enough for the final total to be correct if the presentation along the way is misleading.
Check the amount against the payment solution
When the customer proceeds to payment, WooCommerce sends an amount to the payment solution. After payment, the store receives a confirmation. These amounts must match the order.
Changes made too late in the process can create discrepancies. This includes, for example, pricing rules activated after the payment session has been created, or integrations that change order lines without updating the payment.
The operational process should capture situations where:
- the order was created without confirmed payment
- payment was completed without the correct order status
- the amount paid differs from the order amount
- the customer has attempted multiple payments for the same order
- a change or refund has been recorded in only one system
Such incidents should end up in a clearly defined exception queue. They should not depend on an employee happening to notice them.
Treat refunds as part of the pricing flow
Pricing work does not end when the order has been paid. Returns, cancellations and partial refunds must be traceable back to the correct order lines, taxes and payment events.
A partial refund is more complex than deducting an amount from the order total. The business must know which product was returned, how much VAT should be reversed, whether shipping should be refunded, and whether inventory should be increased.
Define where refunds should be initiated. If employees can create refunds in WooCommerce, the payment portal and the accounting system, the risk of duplicate work and conflicting statuses increases. Choose one standard workflow and describe the exceptions.
Build a test matrix with real pricing scenarios
A test order containing one standard product is not sufficient. Create a fixed test matrix covering the combinations the business actually sells.
It could, for example, include:
- regular product without a discount
- variant with a different price from the standard option
- promotional price combined with a discount code
- order above and below the free-shipping threshold
- private customer and business customer
- different VAT classes in the same shopping cart
- partial refund of one order line
- order with many units and a possible rounding discrepancy
For each test, compare the product page, shopping cart, checkout, order, payment solution and accounting system. Note the expected result in advance. This way, you test against a rule, not merely against what the system happens to display.
Treat pricing discrepancies as an operational responsibility
The pricing flow must also be monitored after launch. Product changes, new discount extensions, adjusted shipping rules and updated integrations can change the calculation without the error being immediately visible.
Establish a few specific checks: orders with a negative total, unusually large discounts, missing VAT, differences between the amount paid and the order amount, and integrations that reject order lines. Assign responsibility for who investigates, corrects and documents the discrepancies.
The most important control is organizational, however: Pricing rules should not be changed as isolated settings. Every change must be assessed across the entire chain, from product and checkout to payment, order processing, refunds and accounting. This ensures that the price is not only correct on the screen, but throughout the entire transaction.
