There is a version of this integration that takes an afternoon. An order comes in, you map a handful of fields, you POST an invoice to Merit Aktiva, it works. You demo it, everyone is happy.
Then a real order arrives. It has a coupon code, two products at different VAT rates, and the customer paid in euros but is a registered company in Sweden. Merit rejects it - or worse, accepts it with a total that is two cents off. Now your accountant has a reconciliation problem at month end, and nobody can say why.
We have built and inherited a number of these syncs. If you want the resilient, event-driven shape of one - webhooks, a queue, idempotency, monitoring - we wrote that up separately in a real integration architecture. This post is about the part the demos skip: the data that does not map cleanly.
The "out-of-the-box" illusion
A marketplace extension is built against the vendor's idea of a normal order: one VAT rate, one currency, no discounts, a simple product. That order does not exist in a real Estonian store for long.
The first time a real edge case hits, an off-the-shelf sync does one of two things. It throws an error - annoying, but at least visible. Or it silently produces a wrong invoice. The silent version is the expensive one, because you find out weeks later, in the accounting, after dozens of bad documents have piled up.
The edge cases below are not exotic. They are Tuesday.
VAT is not one number
Magento tracks tax per line and as order totals. Merit wants a VAT rate on each invoice line. The translation breaks in three predictable places:
- Mixed-rate carts. One cart can contain items at the standard rate and items at a reduced rate. You cannot send Merit a blended average - each rate needs its own line. A sync that copies a single order-level rate gets every mixed cart wrong.
- EU B2B reverse charge. A company customer with a valid VAT number in another member state should be invoiced at 0% with a reverse-charge note. Your transformation has to detect the VAT ID plus country and choose the correct Merit VAT treatment, not just copy whatever percentage Magento happened to apply.
- Rounding. Magento may compute tax on totals while Merit recomputes per line. Pennies drift apart, and a document that is off by a cent is a document someone has to fix by hand.
Discounts have to land somewhere
A cart price rule or coupon spreads a discount across line items, or holds it at the order level. Whatever Magento did, the Merit invoice still has to sum to the amount the customer actually paid.
Map list prices and forget the discount, and the invoice total is higher than the payment - the books do not balance. You have to choose, consistently, between pushing discounted unit prices or adding an explicit discount line. Pick the wrong approach for a given rule and the VAT on the discount comes out wrong too.
Multi-currency and rounding
order_currency_code is not always base_currency_code. A store selling into Sweden takes SEK orders; Merit needs the document in a currency it knows, at a rate that matches the actual payment.
Then there is the cent. The sum of your invoice lines has to equal Magento's grand_total. Two cents of rounding drift is enough for Merit to reject the document, or for reconciliation to flag it forever. Reconcile the line sum against the grand total before you send, and decide explicitly where the leftover rounding goes.
Configurable and bundle products
Magento sells a configurable product - a T-shirt - but the order line is the simple child (T-shirt / Blue / L) with its own SKU, while the parent carries a different one. Bundles explode into components.
Merit wants the SKU that exists in your item register. Decide which SKU is the source of truth and map to it every time. Send the parent when your inventory tracks children, and you create phantom items in your accounting that match nothing.
Refunds are not negative orders
A credit memo is not "the order, but with a minus sign." Partial refunds, refunds with restocking, refunding shipping but not the goods - each maps to a Merit credit invoice that must reference the original document. Drop the reference and your accountant gets a floating credit they cannot match to anything.
What the Merit API actually does to you
- Auth on every call. An API ID plus an HMAC signature. Clock skew on your server breaks the signature, so keep its time synced or spend an afternoon debugging "401" for no visible reason.
- No idempotency on their side. POST the same sale twice - a webhook retry, or a customer hammering "place order" on a slow checkout - and you get two invoices. Once-only is entirely your responsibility. (The idempotency-key pattern is in the architecture post.)
- It is someone else's service. It will be slow or down at some point. A design that creates the invoice synchronously inside the checkout request will eventually hang a customer on Merit's latency. Decouple it from the order flow.
- The silent 200. The API can return success without the record landing the way you expect. A daily count of orders in Magento versus invoices in Merit is the only thing that reliably catches this class of failure.
This is an architecture problem, not an extension problem
Each item above is small. Together they are the reason "just install the extension" turns into months of accountant complaints.
Build the integration as a transformation you can actually test - fifty unit tests covering VAT, discounts, currencies, and refunds - feeding a queue you can retry, not a black box you cannot inspect. The edge cases do not go away. You just want them failing loudly in a test, not quietly in the books.
We have done these edge cases on live Estonian stores. If your Magento to Merit Aktiva (or Directo, or Standard Books) sync is producing invoices your accountant has to fix by hand, talk to us.
Frequently Asked Questions
Why does a Magento to Merit Aktiva integration produce wrong invoices?
The most common cause is a transformation layer built against a simple "one VAT rate, one currency, no discounts" order that does not exist in a real store. Real orders contain mixed-VAT line items, coupon discounts spread across products, and B2B EU reverse-charge requirements. An integration that passes Monday's demo fails Tuesday's real order because the edge cases were never mapped - or were handled with assumptions that break on real data.
How do you handle VAT correctly in a Magento-Merit Aktiva sync?
Merit Aktiva requires an explicit VAT rate on every invoice line item. Magento tracks tax per line and as order totals. The transformation must map each order line to a Merit line with its specific rate - not apply a blended average or a single order-level rate. Mixed-rate carts (standard and reduced rate items in one order) must produce separate Merit lines. EU B2B orders with a valid foreign VAT number require 0% with a reverse-charge note.
How should refunds be handled in a Magento-Merit Aktiva integration?
A Magento credit memo must produce a Merit credit invoice that references the original sales document number. Partial refunds, shipping-only refunds, and refunds with restocking all map differently. Sending a credit document without the reference to the original invoice creates a floating credit in the accounting that the accountant cannot match - generating reconciliation work every month.
What is EU B2B reverse charge and how does it affect invoicing?
EU B2B reverse charge applies when a registered company in another EU member state purchases from your store. The invoice is issued at 0% VAT, with a note that the buyer must account for VAT in their own jurisdiction. In a Magento-Merit Aktiva integration, the transformation layer must detect a valid foreign VAT number plus non-Estonian country code and select the correct Merit VAT treatment - it cannot simply copy the tax rate Magento computed.
How do you prevent duplicate invoices in Magento-Merit Aktiva integration?
Merit Aktiva's API does not prevent duplicate document creation on repeated POST requests. If a webhook fires twice - a network retry, a timeout, a customer double-clicking "place order" - two invoices are created for one order. The correct fix is an idempotency layer in the middleware: before calling Merit, check a Redis key containing the Magento order ID. If present, skip the call. If not, make the call and write the key with a seven-day TTL.