Of all the parts of getting Webflow orders into Xero or QuickBooks, tax is the one that quietly causes the most damage. An invoice that is correct in dollars but wrong in tax still posts wrong books, and you usually do not find out until you file. This post covers how Webflow tax should map into your accounting, how per-region rules work, and why checking the posted tax against the order is the part that protects you.
Why tax is the risky part
A Webflow order total is easy to get right. The tax inside it is not, for two reasons.
First, tax is not a single number bolted onto the order. It is a rate applied to the taxable lines, and your accounting system has its own way of representing that rate: a tax rate in Xero, a tax code in QuickBooks. Posting the right total with the wrong tax treatment still leaves your tax accounts wrong.
Second, the rate depends on where the order is going. A store selling into several US states, or into multiple EU countries, does not have one tax rate; it has one per destination. A setup that assumes a single rate will silently misstate tax the moment an order ships somewhere else.
So the job is not “copy the tax figure across.” It is “reproduce, inside Xero or QuickBooks, the exact tax the customer was charged, for this order’s destination.”
How Webflow tax maps into your accounting
Webflow can add tax on top of your prices at checkout, or show prices with the tax already included, which is usual for EU consumer stores. Either way it records the tax it charged on the order. The clean way to mirror that into accounting is to map, not to copy.
You map your Xero tax rates or QuickBooks tax codes to the orders they apply to. Then, when an order posts, the mapped rate drives the tax your accounting system computes on the invoice lines. Because the invoice is built from the same line items at the same prices, posted as tax-exclusive or tax-inclusive to match how your store charged them, the tax your ledger computes should reproduce the tax Webflow charged.
That “should” is important, and it is exactly what the reconcile guard checks (more on that below).
Per-region rules: US sales tax and EU VAT
A single default rate covers a simple store. A store selling across regions needs the rate to follow the destination.
The pattern that works is a default plus overrides:
- Set a default tax rate for the common case.
- Add per-region rules that override the default for specific destinations. The most specific match wins: a country-plus-region rule beats a country rule, which beats the default.
For US sales tax, that means mapping the states you have nexus in to the corresponding tax codes, so an order shipping to California picks up the California treatment and an order to a state you do not collect in does not.
For EU VAT, under the One-Stop-Shop scheme you charge the destination country’s rate, so you map each EU destination country to that country’s VAT code in your accounting. An order to Germany posts with the German VAT code, an order to France with the French one. This is you mapping your own rates to your own codes, deliberately, not a black box guessing your VAT position. It keeps you in control of a part of accounting where being in control matters.
If your store only ever charges one rate, you never touch any of this. The per-region rules are there for when you need them.
The part that protects you: checking the posted tax
Xaldro checks tax twice. Before posting, it checks that the invoice lines and the order’s tax add up to what the customer paid. After posting, it reads the invoice back from Xero or QuickBooks and compares the total and the tax with the order.
Two things follow from that:
- If an order carries tax but no tax code is mapped, the order is held with a message telling you to set your tax rate, then retry. No invoice is created.
- If the mapped rate does not reproduce the order’s tax (say the wrong code got mapped to a region), the read-back finds a total or tax that differs by more than 1 cent. Xaldro then voids the invoice it just created and holds the order with the reason.
The orders whose mapping is wrong show up as a short list of held orders instead of hiding in your filing.
The tax-free order
Say you map a default tax rate, then a tax-free order comes through: a tax-exempt customer, or a B2B sale that carried no tax. Applying the default rate would make your accounting system add tax the customer never paid. So Xaldro applies a tax code only when the order actually carries tax, and a tax-free order posts tax-free even with a default rate mapped. On a non-US QuickBooks company an untaxed line still needs a code, so map a zero-rate code there; without one the order is held.
What good looks like at month-end
With tax mapped and every invoice read back, every synced order’s posted total and tax were compared with what was charged. Anything that could not post cleanly sits in a “needs attention” list with the reason attached, usually a new destination that needs a rate mapped. You map it, retry, and it posts.
Getting started
Xaldro posts your Webflow orders into Xero or QuickBooks with tax handled the way described here: map your Xero tax rates or QuickBooks tax codes, add per-region rules when you need them, and every invoice is read back so a total or tax that differs by more than 1 cent is voided and held with a reason. You stay in control of your tax treatment; Xaldro is not a tax-filing service.
Each plan is a flat monthly price, and the free trial runs 14 days or your first 100 synced orders, whichever comes first, with no card required.