VAT pipeline is partially built and systematically wrong

Your read is correct. The booking-wizard “Grand Total (excl. VAT)” is package + add-ons (commission-inclusive). The payment page total is not that number plus VAT. It is that number with extras counted a second time, then VAT.

On pay-at-checkout, the server stores quote.amount = checkoutSnapshot.totalAmount, and that snapshot is baseSubtotal + extraOptionsTotal. Payment then does:

chargeAmount = quote.amount * (1 + commission%)
chargeAmount += extras * (1 + commission%)

Harness with package 410.68 + extras 80 + 20% commission: overview customer net 588.82. Payment net if quote already includes extras: 684.82. The extra 96 is exactly 80 × 1.20 charged twice.

€576.43 → €821.58 is the same shape plus VAT. If payment is 21% on (overview + one extra commissioned-options add), implied net is 678.99 and the second extras add is 102.56. That matches “original service amount already includes the options.”

The payment UI tries to split “Original Service Amount” vs “Selected Options” by prorating originalAmount against quote.amount + options. That split is cosmetic. Stripe is charged totalWithVat from the inflated net. The schedule step on the same page also lists quote.amount (already including extras) and then lists extras again.

Unit tests already expect verified NL B2B to reverse-charge to 0%. Belgian B2B is intentionally not exempt (B2B_SAME_AS_B2C_COUNTRIES = BE, CH, LI, NO, GR). That part of the product spec is in code.

The Rotterdam screenshot still shows “Estimated VAT (6% reduced rate)” and “Renovation of dwelling older/equal than 10 years — 6% VAT”. That is a Belgian reduced rule. Three gates all have to pass for 0%, and the wizard fails them:

So a Dutch service address + Dutch company address + NL VAT number can still produce Belgian 6% if the profile location is Belgium or empty, or if the stored country string is Nederland (Dutch name, not in the alias table). The screenshot had “Same as profile address” unchecked: VAT never reads that field.

Two more paths that keep Belgian rates even after a correct NL decision:

VAT number prefix is never the jurisdiction. There are no tests for booking/quotation country precedence or quote-line override vs B2B.

You want two legal documents with different prices and VAT:

What ships today: a single PDF numbered INV-YYYY-NNNNNN, always selfBilling: true. Header issuer is platform company settings. Bill-to is the customer. “Supplier” is the professional. That is not either of the two invoices above.

Generation runs on Stripe payment authorization. A second call at completion no-ops if PDF/UBL already exist. Extra costs declared at the end of the job are therefore too late for the invoice, which is exactly why you generate at completion.

Admin “UBL (Peppol: skipped)” is the literal peppolDispatchStatus. Dispatch returns skipped when the booking is not Belgian B2B, or when platform eInvoicing.peppolEnabled is false (schema default).

If both gates pass and provider is Odoo, the code creates an account.move, optionally posts it, attaches UBL, and returns status queued with reason “Invoice created in Odoo; send via Odoo Peppol workflow”. There is no Peppol send API call. Status sent is never written on this path.

The 7 July Odoo drafts for “Fixera E2E Test Customer BV” (100 € + 21% = 121 €, number /, Peppol column empty) match integration-time test invoices sitting in Concept, not a working Peppol delivery. That also matches “I did receive 2 invoices when you were integrating Odoo.”

Two different models are mixed:

Harness, 20% commission, professional 490.68, customer net 588.82: professional should receive 490.68 and platform 98.14. Actual payout helper: professional 471.06, platform 117.76. That is (1+c)×(1−c) = 1−c² of the professional amount (96% at 20%), not 100%.

Stripe transfer uses booking.payment.professionalPayout. Extra costs at completion live on the booking, not the Payment row the admin oversight table reads. So the ledger never shows end-of-job extras, even when the customer paid them.

1.A. Controlled input value is options.join(', '). Each keystroke does split(',').map(trim).filter(Boolean). Typing a comma produces an empty token that is deleted, so the comma vanishes. Spaces inside an option (“foo bar”) work. The space after a comma cannot be typed because the comma never survives. That is the red box in the VAT admin screenshot. The same eager-parse lives on professional dropdown options in the same admin form.

1.B. “Chat for quotation” is StartChatButton with only professionalId. VAT answers exist only after booking create, on vatDecision.answers / booking detail — not in the first chat message. The professional has no structured dump of wizard fields.

7. Quotation VAT is a Select of rates from GET /api/quotations/:id/vat-rates. Country is vatDecision.country || customer.location.country || BE. Fallback option is 21% BE. Submit rejects any rate not in that list. There is no numeric field and no comma-decimal parser. Admin logic-rule rates use type="number" step={0.1}, which also fights comma locales.

Do not start from Peppol or invoice chrome. The customer-visible money and VAT country are wrong first.