"Pollie" POS Complex GST logic

Officeworks 2025-2026

Pollie POS is Officeworks' in-house POS software. It combines a JQuery/Handlebars/React frontend with a .NET Core/C# backend connected to SQL Server databases. Pollie POS handles thousands of transactions daily and ensuring its uptime is critical.

The Problem

Officeworks had recently become a preferred supplier for the Federal Government, and part of the way that the Government purchases supplies requires a 4% Coordinated Procurement (CP) Fee to be added by the supplier, who then holds the fee for some period of time before paying the fee back to the Government, similar to how GST operates.

Because the transaction is not between Government departments, the CP Fee attracts GST, which wouldn't usually be a problem -- however, Officeworks sells some products that don't incur GST (e.g. instant coffee). GST must be correctly calculated in order for printing on receipts, and both GST & CP Fee need to be sent through to SAP for sales reporting.

Challenges

Identifying items that do or do not attract GST in Pollie is pretty straightforward, but up until this feature was implemented, items either included GST, or didn't. In this new scenario, I had to handle the case where the item itself didn't have GST, but the attached CP fee did.

Because the Federal Government had contract pricing with Officeworks, instead of the normal pricing we'd rely on at POS fetched locally from the database, we had to fetch the adjusted prices (-discount+CP fee) including GST from SAP on an ad-hoc basis. Since the prices we were fetching were GST inclusive, we were required to change how GST was derived for non-GST items.

Solution

For GST inclusive items, deriving the total amount of GST paid is quite simple:

For GST exclusive items, in order to derive the total amount of GST paid, first we start with how the item total is calculated:

From here, we can convert cpFee and cpFeeGST to be relative to itemPrice. CP Fee is 4% of the item price, and GST is 10% of CP Fee, which is the same as 0.4% of the item price:

Now we can group together the like terms and simplify the equation:

Inverting the equation gives us the itemPrice from the itemTotal and then we can recalculate the GST paid from the itemPrice:

It turned out that the calculation for GST paid on items where only the CP Fee included GST was also pretty simple -- just not as intuitive to get to.

Results

The CP Fee changes went into the build without issue. PVT testing showed that both CP Fee and GST were reporting correctly for GST-exclusive items. Most of the Federal Government transactions were completed online through our website, but the smaller amount of transactions that were processed in-store went through without a hitch.

Retrospective

This problem was interesting because, for business reasons, we couldn't have our business pricing endpoint provide the Federal Government prices without the CP Fee applied. If this wasn't the case, we could simply apply the CP Fee at POS and then just send the fee and GST values through to SAP without much issue.

Behind the scenes, SAP was applying the same 1.04x or 1.044x multipliers to the prices before they were sent to us, where we then had to divide and recalculate, etc. It felt a bit like doing the same work twice. Ideally we could have worked together for a configurable pricing endpoint for both web orders and in-store purchases.