There is a quiet failure mode in every accounting integration: it posts an invoice that looks right and is wrong by a few cents. Multiply that across a month of orders and your bank deposits no longer match your ledger. Now someone has to find the gap by hand.
A wrong invoice is worse than a missing one
If an order never posts, you notice. It sits in a queue, it is obvious, you fix it. If an order posts short by the tax, nothing looks broken until reconciliation day, when the totals refuse to line up and you are hunting through dozens of invoices for the one that is off.
So the right default is not “post and hope.” It is: reconcile to the cent, or hold the order.
How the guarantee works
Before Xaldro posts an order, it builds the invoice (line items, shipping, discount, tax) and checks the total against what the customer actually paid. Two outcomes:
- It matches. The invoice posts, with the Webflow order ID in the reference.
- It does not match. The order is held and labelled with the exact reason, for example “this order includes 8.19 of tax, but no sales tax code is mapped for this system.”
You then fix the mapping in Settings and retry. Nothing wrong ever reaches your books.
Fetch-back verification
Holding before posting is half of it. The other half is checking after. Some accounting systems quietly recompute tax on their side based on the customer’s location. So after Xaldro posts, it fetches the invoice back and compares the posted total to the order total. If the system changed the number, Xaldro voids the invoice it just created and holds the order instead. You are never left with a posted-but-wrong entry you did not know about.
Why this matters for agencies
If you keep books for several Webflow clients, “reconciles to the cent” is the difference between a five-minute month-end and an afternoon of detective work per client. The held-for-review list becomes your entire to-do list: a short, explained set of exceptions, instead of a pile of invoices you have to audit one by one.
That is the whole idea. Your job at month-end should be reading a short list of clearly explained exceptions, not re-checking everything the software already did.