Craft Commerce 5 · Netherlands & Belgium
The half of the integration nobody builds
Every Moneybird bridge on the market creates a contact and an invoice and stops there. The parts that actually cost a bookkeeper an afternoon are the ones that get skipped: reverse charge that is a different 0% from an export, One Stop Shop rates per destination country, refunds that give the VAT back at the rate it went on at, and totals that reconcile to the cent against a bank feed. Bird is those parts.
See it before you send it
There is exactly one place in the code where a Commerce order becomes Moneybird JSON, and the Preview button runs it. What you are shown before booking is byte-identical to what gets booked — tax rate ids included, which is where the mistakes actually live.
{% set document = craft.bird.documentForOrder(order) %}
{% if document and document.getIsBooked() %}
<p>Invoice {{ document.getLabel() }} — {{ document.getStateLabel() }}</p>
{% endif %}
{% set vat = craft.bird.vatTreatment(order) %}
{% if vat.reverseCharge %}
<p>VAT reverse-charged — {{ vat.vatNumber }}</p>
{% endif %}What it actually does
Six things a Zapier-shaped bridge does not.
0% is three different rates
Reverse-charged, exported and genuinely zero-rated land in three different boxes on a VAT return. Bird books which one it was, rather than booking a number and leaving the reason behind.
- Your btw verlegd rate and your export rate are separate settings
- An unmapped rate refuses the order and names the percentage
Commerce decides, Bird books
Commerce's tax engine already knows your zones, your rates and your VAT-number validators. Re-deriving that here would give your shop two answers that drift apart, and the one on the customer's card is Commerce's.
- A VAT number on an order that still paid 21% is not reverse charge
- Bird books what happened, not what could have happened
Rates matched on the money
Commerce rounds tax per line, so €10.10 at 21% records €2.12 — which divides back out as 20.99%. A percentage look-up would refuse ordinary orders every day. Bird matches the rate whose arithmetic lands within a cent.
Totals that match the bank feed
The invoice total equals what the customer paid, because that is the number the bank will show. A cent of per-line VAT rounding goes onto a line at 0% — it is not revenue and should not be taxed as if it were.
- Or turn reconciliation off and Bird refuses those orders instead
It cannot book the same revenue twice
The document table is unique on order, kind and source, and that index is the guarantee. A retried job, a double-clicked button and a webhook racing the queue all collide on it.
- A push that dies mid-flight finds its invoice by reference and adopts it
- Nothing Bird does can stop a customer paying
Paid means actually paid
Bird pushes invoices; Moneybird is where a bank transfer gets matched against one. The webhook tells your site when that happens, verified with HMAC-SHA256 over the raw body and rejected beyond five minutes.
- No secret, no signature, no stale timestamp, no request
- Can move the Commerce order's status when the invoice is paid
Frequently Asked Questions
The questions worth answering before you install it.
No. Bird is an independent plugin built by Justin Holt, and it talks to Moneybird's public API the same way any other client would. It is not affiliated with, endorsed by, or sponsored by Moneybird, and “Moneybird” is a trademark of its respective owner.
Lite is, and it is not a trial. Invoices, contacts, payments, domestic VAT, reverse charge, export and the rounding reconciliation are all in Lite for nothing. Pro is a one-off $99 with a $49/year renewal, and adds One Stop Shop, credit notes for refunds, sending from Moneybird, the signature-verified webhook, per-product-type ledger accounts and the connection log.
If Moneybird is where your invoices come from, you want sales invoices — Moneybird numbers them, renders the PDF and can email them. If your shop already issues its own invoices and you only need the bookkeeping to be right, you want external sales invoices: the order reference is the invoice number and Moneybird just books the revenue and the VAT. It is one setting.
No, and that is the design. Commerce's tax engine already knows your zones and your rates, and the answer the customer actually paid is Commerce's. What Bird adds is the reason, because Moneybird needs to know which 0% it is looking at.
Because the order charged 21%. Reverse charge is a claim about what was charged, not what could have been, and booking it as reverse-charged would understate your return by exactly what the customer paid. The cause is nearly always Commerce's VAT-number validator being switched off — turn it on and future orders zero-rate at checkout.
No. Everything that runs during checkout fails open, and the push goes through the queue by default. A Moneybird outage, an expired token or a rate limit produces a failed document row and a retry. It cannot produce a customer who could not pay.
Nothing, until you ask. Backfill brings them across, and a dry run reports every order it would book, under which VAT treatment, without sending anything.
Craft CMS 5.3+, Craft Commerce 5.0+ and PHP 8.2+.
Start free, upgrade when you cross a border
Lite books invoices with correct domestic, reverse-charge and export VAT, for nothing. Pro is $99 with a $49/year renewal, and adds One Stop Shop, credit notes, sending, the webhook and the connection log.