WooCommerce matches location patterns and priorities, Stripe applies defined tax rate records, and ERPNext uses tax rows selected directly or through rules.
Key takeaways
- Trace the rate used on a normal sale.
- Test known cases in a test environment.
- Check customer records and tax settings.
- Give staff a clear contact for tax questions.
Why the rate on the till matters
Every taxable sale needs a rate. If the software picks the wrong one, the shop can collect too little or too much tax. The sale record, the till report, and the figures used at tax time can then disagree with each other. Most people who work a till never see how that choice is made. The software makes the choice automatically, using settings that someone entered earlier.
Owners and managers usually know which rates the shop should charge. Till staff usually know the price on the screen. Fewer people know the rules that connect the two. Knowing how your software reaches its answer makes it much easier to spot a mistake before it affects a week of sales.
How we compared them
We looked at three widely used systems that handle sales tax: WooCommerce, Stripe, and ERPNext. Each publishes official documentation on how tax rates are set up and applied. We did not test any of them on a live till, and we did not rely on third-party reviews. Everything quoted here comes from the vendors' own pages.
We compared them on four points:
- What information the software uses to choose a rate, such as the sale's location, the customer, the product, or the date.
- What happens when more than one rate could fit the same sale.
- Where the rate is stored, and whether it is attached to the sale record.
- What a staff member can see on the screen or in a report afterward.
One caution: this is a comparison of documented tax features. Stripe's Tax Rates guide covers invoices, subscriptions, and payments through Checkout. The till app you use may follow a different path. Use this comparison to learn which questions to ask, not as a description of your own till.
WooCommerce: location fields and priorities
WooCommerce matches a sale's address against rate location fields, which accept patterns. The official documentation gives this example of a postcode pattern ( WooCommerce tax setup guide):
> "For example, PE matches all postcodes beginning with PE, and 90210 matches ZIP+4 postcodes beginning with 90210."
A short pattern can cover a whole area, and a longer one can cover a smaller one. Someone who edits a postcode pattern can change which sales get that rate, so treat the field as a setting with real effects on tax. Ranges work the same way. The same guide explains:
> "Use a numeric range, such as 2000…3000, to include all values between the start and end."
A range typed slightly wrong can pull in more codes than intended, or leave out some it should include. A quick check of the start and end numbers is cheap insurance.
The bigger question is what happens when two rows both match. The guide describes the order:
> "Priority 1 is considered before priority 2, which is considered before priority 3, and so on."
This matters when a shop has a general rate and a narrower local rate for the same area. The priority number decides which is considered first. The documentation describes that order, but it does not replace a test. Check which rate ends up on a sale to a customer in an overlapping area.
WooCommerce also lets a shop show prices with tax included. The guide gives this example of how a display setting appears on a page ( WooCommerce tax setup guide):
> "For example, entering Price incl. tax: {price_including_tax} displays as “Price incl. tax: $59.74” in your store."
A label that says the price includes tax does not, by itself, show which rate produced the number. Compare the displayed price with the tax line on the sale record before trusting either one. For related checks, see enter shop prices with tax in WooCommerce.
For a shop with a few rates, this model is easy to read. The weak point is the data. A postcode pattern that was correct two years ago may now cover the wrong area, and nobody may notice until a report looks odd. Review the table on a set schedule, and after any change to the shop's delivery or service area.
Stripe: tax rates as their own records
Stripe treats a tax rate as a record you create with its own details, then apply to a payment or invoice ( Stripe tax rate documentation).
> "Stripe allows you to define any number of tax rates and apply them to invoices, subscriptions, and one time payments when using Checkout."
The useful point is that the rate is a defined record that gets applied. The question to ask is which record a given sale used.
The guide also says when this approach fits:
> "Use Tax Rates for cases where you have a fixed set of rates or use a provider without a native integration."
The practical lesson is naming. A name that says only "Tax" or "Standard" will be hard to check later. Keep a written list of active rates.
Because the rate lives in a record of its own, any change to it is a deliberate act that someone in the shop should own. Before you retire or edit a rate, ask the vendor how past sales, subscriptions, and invoices that used it will look afterward.
ERPNext: tax rows and tax rules
ERPNext uses a named set of tax rows. The documentation describes its use across Quotations, Sales Orders, Delivery Notes, Sales Invoices, and other supported selling flows.
When a set is selected, its rows come along with it. The guide explains:
> "Selecting it copies its rows into the transaction, where ERPNext calculates the actual amounts from the items and quantities."
This is an important difference. The tax lines and totals are worked out on the document itself, from its items and quantities. They pick a set of tax rows, or the system picks one for them.
The guide recommends separate sets when the tax jurisdiction, treatment, company, or commercial charge structure differs.
A single set with many exceptions is harder to check at the till and harder to audit later.
Automatic selection is the biggest practical difference in this comparison:
A Tax Rule can select the tax rows automatically using the customer, address, Tax Category, item context, date, and priority ( ERPNext documentation).
Each input in that list is a place the rate can come from. The address is one of the inputs the rule uses. Tax Category is another input. The date means the rule can depend on when the sale happens. Priority is one of the inputs the Tax Rule uses.
With a Tax Rule, the rate can come from data stored on a customer record, not from anything typed at the till. If a customer's tax category is wrong, or an address is out of date, the rule may choose the wrong set of tax rows. The sale then carries the wrong rate even though the counter staff did everything correctly. Catching that means checking the records behind the rule, not just the screen. See merge duplicate customer records for related record checks.
Because the rule uses a date, plan the start date for any rate change. A new set of tax rows that goes live on the wrong day can affect sales on both sides of the change.
Side by side
The table compares rate selection and supported uses.
| Question | WooCommerce | Stripe | ERPNext |
|---|---|---|---|
| What the software looks at | The sale's address, using postcode patterns and numeric ranges | A defined tax rate record applied to the payment or invoice | Tax rows picked directly, or chosen by a Tax Rule |
| What the setup supports | Priority numbers set the order rates are considered in | A fixed set of rates | Rule priority is one of the inputs the rule uses |
| Where it applies | Tax-inclusive price displays in your store | Checkout, invoices, subscriptions, one-time payments | Quotations, sales orders, delivery notes, sales invoices, and other selling flows |
| What staff can see | The displayed price label and the tax line on the sale record | The rate name on the invoice or payment record | The copied tax rows on the document itself |
The table shows that each tool has a different place where a mistake can start. In WooCommerce it is often the location fields. In Stripe it is often the rate record a sale was tied to. In ERPNext it is often the data behind the Tax Rule.
What this means for a till
Whichever tool you use, start by asking where the rate comes from for a normal sale. Is it set by the address, the customer account, the product, the date, or a rule combining several of these? If the answer is "I don't know," fix that first. A rate you cannot trace is a rate you cannot defend.
Next, test a few known cases: a local customer, a customer from an outside area, a differently classed item if your shop has one, and a sale on a day close to a rate change. Work out the correct tax for each and compare it with what the system records. Use a test environment if your software provides one.
Then check the order of rules. If more than one rate or rule can apply, find out what the software does. In your own system the order may be set differently, or hidden in a setting that is easy to overlook. Ask the vendor if you cannot find it.
After that, check the data. Customer records, addresses, tax categories, and product labels feed the rate, and a typo in one can change the tax on many sales. Review these fields on a schedule and after any staff change.
Keep a simple written record of every rate: its name, its percentage, the area or type of sale it covers, who set it up, and when it was last changed. This is the first thing you will need if a report does not match the till.
Finally, check the first sales after any change. A new set of tax rows, postcode pattern, or rule should be followed by a few test sales of each common type. Checking early means you find problems while the sales are still few.
Illustrative example: check the expected tax
Ring the sale in the test environment and read the tax line it records. Compare that with $5, then trace which rate or rule produced it. If the recorded tax differs, follow the rate back through the settings that selected it before you change anything.
Staff at the till
Till staff do not need to understand the whole rule system to protect the shop. They need to know what to look for and when to speak up.
On each sale, glance at the tax line. Does it look right for what was sold and where? If a local customer gets an unusual tax line, or a taxable sale shows none, note the sale and tell a manager. Do not guess at a fix, and do not change a rate or customer record at the counter unless your shop has given you permission.
If the shop shows tax-included prices, make sure the price on the screen matches what the customer is charged. A small gap is easy to miss on a busy shift and easy to repeat.
When a manager changes a setting, ask what changed and when. Till staff are often first to notice a problem, and a short note can save a lot of time. A shared log of tax questions, even a paper notebook, helps the team spot patterns across shifts.
Finally, know who to ask. Every shop should be able to name the person who manages tax settings and the person who can contact the software vendor.
Today, choose a normal sale and ask your tax-settings manager to trace its rate back to the setting that selected it.
Questions to ask your software vendor
- Which inputs does the software use to choose a tax rate for a sale? Inputs differ: WooCommerce uses the sale's address, Stripe applies a defined tax rate record, and ERPNext uses customer, address, Tax Category, item context, date, and priority.
- When more than one rate or rule could apply, what decides which one is used? WooCommerce considers numbered priorities in order; confirm your own system's behaviour.
- Is the rate stored on the sale itself, or looked up again when someone runs a report? Ask the vendor how your sale records retain tax details.
- What happens to past sales if a rate or rule is changed or removed? Confirm the effect on past records before making changes.
- Can a tax rule depend on the customer record, and if so, which fields matter? ERPNext names customer and Tax Category among its rule inputs.
- Is there a way to test a sale without affecting real records? Use a test environment if your software provides one.
- Who in our shop should be able to change tax settings, and does the software enforce that? Your shop should identify who manages these settings and confirm their permissions.
Answers to these questions will tell you more than any comparison. Two shops using the same software can still set it up very differently, so your own answers are the ones that count.