Pronto Xi Ecommerce Pricing Errors: What to Check Across ERP and Online Orders

When an ecommerce price differs from Pronto Xi, do not start by deciding which system is wrong.

First establish whether both systems were pricing the same:

Customer → Product → Quantity/UOM → Pricing rules → Promotion → Effective time → Transaction state

Then identify where the commercial outcome diverged:

Website → Checkout → Integration → Pronto Xi order → Amendment → Invoice → Return

A pricing discrepancy is a symptom.

The objective is to determine whether the cause lies in customer mapping, pricing rules, calculation sequence, timing, synchronisation, integration or subsequent order processing.

For CFOs, this matters because pricing errors can create margin leakage, credits and avoidable administration.

For CIOs, it matters because inconsistent pricing often reveals unclear ownership or poorly understood integration behaviour.

Why can ecommerce pricing differ from Pronto Xi?

Pronto Xi supports pricing structures that can vary according to customer and product attributes rather than relying on a single selling price.

Published Pronto documentation describes pricing based on factors including customer or bill-to account, pricing level, contract, territory, warehouse, customer group, product classifications and quantity-related rules. Pronto also provides discount, promotion and rebate capabilities.

That means the same SKU can legitimately produce different prices under different transaction conditions.

Before treating a difference as an error, establish:

• customer identity;
• item;
• quantity;
• unit of measure;
• warehouse where relevant;
• pricing date/time;
• customer or contract pricing;
• discounts;
• promotions;
• tax treatment;
• transaction status.

The most important principle is:

Two systems cannot be expected to return the same price unless they are pricing the same commercial transaction under the same rules.

First, distinguish three different pricing responsibilities

One of the most important architectural questions is often overlooked.

For each pricing component, distinguish:

Pricing authority

Which system owns the commercial rule or underlying data?

Pricing calculation engine

Which system actually calculates the transaction price?

Price presentation

Which system displays the result to the customer?

These may be different.

For example, Pronto Xi may hold the authoritative customer price, an ecommerce platform may calculate from synchronised data, and the website may then display the result.

Alternatively, ecommerce may request a price from the ERP in real time.

Those designs create different failure modes.

A useful architecture register is:

If the organisation cannot complete this table, troubleshooting will be harder than it needs to be.

1. Are both systems pricing the same customer?

Start with customer identity.

Pronto Xi supports customer-specific pricing, so a pricing difference may simply reflect one system treating the shopper as a different account.

Check:

• Is the customer logged in?
• Which Pronto customer account is linked to the ecommerce user?
• Is the correct bill-to account being used?
• Does the customer belong to the expected pricing group?
• Does contract or special pricing apply?
• Is the transaction being treated as a guest order?

Example

Public ecommerce price:

$120

Customer A contracted price:

$98

If ecommerce fails to identify Customer A correctly, $120 may be internally consistent even though the customer expects $98.

That is a mapping problem, not necessarily a pricing calculation defect.

2. Are both systems starting from the same base price?

Before investigating discounts or promotions, confirm the starting price.

Pronto Xi supports flexible pricing structures including base prices, pricing categories, quantity-related pricing and customer-specific arrangements.

Ask:

• Which price level applies?
• Does a contract price exist?
• Is the relevant warehouse part of the pricing rule?
• Does quantity alter the price?
• Did the underlying price recently change?
• Is ecommerce storing the price or retrieving it dynamically?

A perfectly calculated discount applied to the wrong base price still creates an incorrect result.

3. Is the calculation sequence the same?

This is one of the most common sources of subtle cross-system differences.

Two systems can contain the same data but return different totals if they apply rules in a different order.

For example:

Base price → Customer price → Quantity break → Promotion → Discount → GST → Rounding

may produce a different result from:

Base price → Promotion → Customer discount → Quantity break → GST → Rounding

The exact sequence depends on the organisation's Pronto Xi configuration, ecommerce platform and commercial rules.

Do not assume the order.

Document it.

A useful test is:

Given the same customer, item and quantity, what is the expected calculation sequence from base price to final invoiced amount?

This should form part of both system design documentation and UAT.

4. Are customer pricing and promotions being combined correctly?

Customer-specific pricing, discounts and promotions are different concepts.

Pronto Xi supports flexible pricing and discount structures, while Pronto's retail capabilities include promotional pricing mechanisms such as percentage or dollar discounts, multi-buy and other promotional structures.

Potential questions include:

• Does a contract price override the standard price?
• Can an additional discount apply?
• Can a promotion apply to a contract customer?
• Can multiple promotions compound?
• If several rules qualify, which takes precedence?
• Does the ecommerce system reproduce the same logic?

The key is not merely:

“Did a promotion apply?”

It is:

“Did the correct combination of eligible pricing rules apply in the correct order?”

5. Could rounding explain the difference?

Small discrepancies are often dismissed as insignificant, but at ecommerce scale they can create substantial reconciliation noise.

Determine where rounding occurs.

Possible differences include rounding:

• unit price before quantity extension;
• line value after quantity;
• percentage discounts;
• GST or tax;
• promotional values;
• order totals.

For example, calculating GST on each line and summing the result can differ slightly from calculating GST on the order total.

Similarly:

Unit price × quantity → round

can differ from:

Rounded unit price × quantity

These differences may be legitimate consequences of the configured calculation method rather than product defects.

The important requirement is consistency with the intended commercial and accounting treatment.

6. What point in time determines the customer's price?

Pricing entitlement needs an agreed reference point.

An ecommerce transaction can have several timestamps:

Price displayed → Cart created → Checkout → Payment → Order submitted → ERP order created → Invoice

If a promotion or price change occurs during this sequence, which price should the customer receive?

For example:

A promotion ends at midnight.

The customer:

• adds the product to cart at 11:50 pm;
• checks out at 12:02 am;
• ecommerce transmits the order at 12:03 am;
• Pronto Xi creates the sales order at 12:04 am.

Which timestamp governs?

There is no universal answer.

The organisation needs a commercial rule and the systems need to implement it consistently.

Test boundaries explicitly:

• immediately before promotion start;
• immediately after start;
• immediately before expiry;
• immediately after expiry;
• cart created before expiry and checked out afterwards;
• order accepted before expiry but transmitted afterwards.

Price entitlement should be defined before a dispute occurs.

7. Is ecommerce using live pricing or synchronised pricing?

This depends on the ecommerce platform and integration design.

Pronto describes its current Pronto Xi eCommerce product as tightly integrated with Pronto Xi, including synchronisation of information such as product, pricing, inventory, promotions and orders.

That should not automatically be assumed for third-party ecommerce platforms.

For any ecommerce environment, establish:

• Are prices retrieved in real time?
• Are they copied periodically?
• Is there caching?
• How frequently is pricing refreshed?
• Are customer-specific prices included?
• Are promotions transferred or recalculated?
• How is stale pricing identified?
• What happens if synchronisation fails?

The difference between real-time calculation and periodically synchronised pricing is architecturally significant.

8. Does Pronto Xi preserve or recalculate the ecommerce price?

This should never be assumed.

Test what happens when the order reaches Pronto Xi.

Trace:

Ecommerce order line → Integration payload → Pronto Xi sales order → Invoice

Check whether:

• incoming unit price is retained;
• Pronto pricing logic recalculates it;
• discounts are reapplied;
• promotions are translated;
• rounding changes;
• another process alters the price later.

If the website charged $98 but the Pronto sales order contains $102, identify exactly where that change occurred.

That narrows the investigation dramatically.

9. What happens when an online order changes?

The original checkout is only the beginning.

Orders may later be:

• increased;
• reduced;
• partially cancelled;
• substituted;
• moved to another warehouse;
• amended by customer service.

Those changes may affect pricing eligibility.

For example, reducing quantity may remove a quantity break.

A partial cancellation might affect an order-value promotion.

The business needs to decide:

Should the accepted ecommerce price be preserved, or should the order be repriced when it changes?

There may be different rules for different types of amendment.

Those rules should be explicit and regression-tested.

10. What happens on returns and credits?

Current pricing and historical pricing are not necessarily the same.

A customer may return an item weeks after:

• the promotion ended;
• the standard selling price changed;
• their contract pricing changed.

Pronto Xi Sales supports credit processing and can use information from original invoiced transactions.

Test:

• full return;
• partial return;
• partial multi-buy return;
• exchange;
• price correction;
• return after promotion expiry;
• discount correction.

The key question is:

Which historical commercial values should be preserved when a transaction is reversed?

11. Can integration retries create duplicate or inconsistent transactions?

Successful integration is only half the test.

Failure recovery matters just as much.

Suppose:

1. Ecommerce submits an order.
2. The connection times out.
3. Ecommerce cannot tell whether Pronto received it.
4. The transaction is retried.

The integration should prevent one valid customer order from accidentally creating two ERP orders.

This property is sometimes described technically as idempotency or duplicate-safe processing.

The practical business requirement is simpler:

One accepted customer order should result in one correct Pronto Xi transaction, even when communication fails and retries occur.

Test:

• connection timeout;
• application error;
• queued transactions;
• automatic retry;
• manual retry;
• repeated submission.

Then reconcile both systems.

A practical pricing investigation decision tree

When ecommerce and Pronto Xi disagree, use this sequence.

1. Same customer?

No → investigate customer/account mapping.

2. Same item, quantity and UOM?

No → correct the transaction comparison.

3. Same pricing authority and base price?

No → investigate pricing level, contract or source data.

4. Same calculation sequence?

No → investigate rule precedence, discounts, promotions, GST and rounding.

5. Same entitlement time?

No → investigate effective dates and transaction timestamps.

6. Same synchronised data?

No → investigate integration, caching or stale pricing.

7. Same value when ecommerce submits the order?

Yes, but Pronto differs → investigate order import or ERP repricing.

8. Same ERP order but invoice differs?

Investigate amendments, invoicing rules or later transaction processing.

9. Return differs?

Investigate historical pricing and credit logic.

This gives teams a far more useful diagnostic path than starting with:

“Pronto pricing is wrong.”

Build a golden-order regression pack

One of the best controls is to maintain a small set of known pricing scenarios whose correct results are documented.

These golden orders can be rerun after:

• a Pronto Xi upgrade;
• ecommerce release;
• integration change;
• promotion-engine change;
• pricing configuration change.

Examples:

For each golden order retain:

Inputs → Expected calculation → Expected ecommerce value → Expected Pronto order → Expected invoice

This transforms pricing validation from a one-off project activity into a reusable control.

Monitor pricing differences before customers report them

Mature controls should not rely entirely on complaints.

Depending on the architecture and available data, organisations can monitor indicators such as:

• ecommerce order value versus Pronto order value;
• manual price overrides;
• pricing-related credit notes;
• orders changed after import;
• synchronisation failures;
• rejected transactions;
• stale pricing feeds;
• repeated integration retries.

The objective is not to generate another dashboard for its own sake.

It is to answer:

Are pricing discrepancies increasing, recurring or concentrating in a particular customer, promotion or integration path?

That can identify systemic problems earlier.

Measure pricing leakage separately from administration cost

For CFOs, pricing discrepancies have at least two economic consequences.

Direct pricing leakage

Where a verified pricing error produces an undercharge:

Expected transaction value − actual transaction value = pricing leakage

Aggregate validated errors rather than estimating from anecdotal complaints.

Remediation cost

Then consider:

• credits;
• refunds;
• customer-service time;
• Finance reconciliation;
• IT investigation;
• manual order correction.

An overcharge may not create margin leakage, but it can create substantial remediation cost and customer risk.

Keeping these categories separate produces a cleaner business case for fixing recurring issues.

Who owns ecommerce pricing accuracy?

Pricing crosses several functions.

IT can determine where systems differ.

The business must determine what the correct commercial result should be.

What evidence should be captured when an error occurs?

For material or recurring discrepancies, retain:

Customer → Product → Quantity/UOM → Pricing authority → Base price → Calculation sequence → Discount/promotion → Timestamps → Ecommerce value → Integration record → ERP order → Invoice/credit → Root cause

Then classify the cause.

This is a much stronger basis for escalation than simply reporting that “the price is wrong”.

Pronto Xi ecommerce pricing checklist

When online and ERP prices differ, check:

• Correct Pronto customer/account
• Correct product/SKU
• Same quantity and UOM
• Same warehouse where relevant
• Pricing authority identified
• Calculation engine identified
• Presentation source understood
• Same starting/base price
• Customer or contract pricing considered
• Quantity breaks considered
• Discount rules checked
• Promotion eligibility checked
• Rule priority/compounding verified
• Calculation sequence verified
• Rounding method compared
• Price-entitlement timestamp defined
• Synchronisation/caching behaviour confirmed
• Incoming ecommerce price compared with Pronto order
• Repricing on amendments understood
• Returns/credits tested
• Integration retries tested for duplicates
• Exact divergence point identified before declaring a software defect

If these questions cannot be answered consistently, the organisation has a pricing-governance and architecture problem, not merely a collection of isolated order errors.

Need Pronto Xi capability to investigate ecommerce pricing?

Recurring pricing problems can cross Pronto Xi Sales, Inventory, customer pricing, promotions, ecommerce and integration architecture.

If an investigation identifies gaps in Pronto functional, technical, integration, BA or testing capability, SAAPRO can help assess specialist availability in the Australian Pronto Xi market.

Disclosure: SAAPRO is an independent Pronto Xi recruitment specialist and is not Pronto Software or an ecommerce implementation vendor.

Exact pricing, promotion, repricing, integration and return behaviour depends on the organisation's Pronto Xi configuration, ecommerce platform, integration architecture and commercial rules.