Handling rounding and VAT in order integration

One potential challenge in order integration relates to the disparate methods employed by various systems and businesses for managing VAT and rounding of prices on sales orders. If an ERP or OMS that received the order from Norce expects the calculation differently, errors might occur that need to be handled by the integration and sometimes by manual input.

VAT and rounding in Norce

First, lets look at how Norce calculates the amounts on the Order.

1. A unit price is saved on the order row (best price from the product)
2. A VAT is added, based on the product's VAT rate (rounded according to client settings)
3. The row is multiplied with quantity to give the row amount
4. All row amounts (from 3) adds up to the order total amount
5. All VAT's (from 2) multiplied by quantity and aggregated from all rows is the total VAT

This method works with most PSP's currently used with Norce, __which is important since they will not be able to capture the correct amounts otherwise later on.

However, some ERP systems work differently. For example, some want to calculate the VAT after they multiply the quantity with (i.e. switch 2 and 3 in the list above). And if the quantity is high and the ERP also makes nicely rounded subtotals, the risk of discrepancy between how Norce and the ERP gets quite high.

On certain occasions, especially when dealing with orders containing large quantities, discrepancies in the two calculation approaches can cause significant variations, potentially triggering error messages from the ERP system during order submission.

Solving the discrepancy problem

Sadly, there is no easy way to fix this problem.

Norce have chosen our way to calculate this, based on how most PSP's and eCommerce solutions does it, and we must adhere to their way, so not to have problems later, when payment captures, credits or cancels are done.

A common way we have seen solutions handle this is to flag orders for manual adjustments when passed into the ERP system. Using a tolerance threshold and a " manual check" flag that is passed in by the integration on the order.

Tolerance

Set up the integration so that some tolerance is allowed. Let some small discrepancies through and, if the amount that differ is too big, add a manual check where the order is adjusted. This is preferably done by passing in a "manual check" flag on the order to the ERP system.

Manual checks

For an order already reserved by a PSP, the VAT is already a fact and cannot be changed, and the same for the total amount. It is the other parts that needs to be adjusted.

• If you use partial capture each row must add up (or a bit lower) to the ecommerce order line amount, compensate for this in the ERP.
• Calculate backwards and use centrounding rows for compensating the last diff in needed.

Payment method

Not all orders might need this treatment.

An order that is marked to be invoiced from the ERP doesn't have to follow the VAT Norce has calculated and can just recalculate the VAT in the integration.

Amount focused payment methods, like Credit card or bank transfers are only concerned with the total amount and doesn't care about VAT. In this case adjustments of the line amounts are easier to do as well.

Example 1 on rows

Three examples on how the row amount might differ between Norce and the ERP

First how Norce will calculate it:

Let's look at how the ERP would calculate the same lines, and see the amount that differs.

If we have a tolerance check for everything over 1.00#, the third line would be marked for manual check.

In the manual check, the handler can adjust the ERP order, by changing the unit price so that the VAT amount is correct.

Where row CR is a centrounting line, to make the total add up.

In this case the unit price was adjusted with an additional centrounding row to set the correct total amount.

Alternatively, when the payment methods is amount focused (credit card) the adjustment could be simpler

Here the original unit price works fine, because the total amount is lower than the reserved amount by the PSP (15290). The centrounding is optional, if one prefers a nicer total of 15288.00

Example 2 - whole order

Let's look at one whole order with to rows.

Norce order:

ERP Order:

Both rows require manual checks based on the tolerance. In the manual check, the handler can adjust the ERP order as a whole, by changing the unit prices so that the VAT amounts are correct.

Alternatively, for credit card paid orders, and only caring about the total amount the adjustment is the same in this case

Suggested further reading