eMAG ex-VAT pricing and min/max, explained
Two rules behind most price-publish failures
Most price-publish failures on eMAG come down to two rules sellers learn the hard way: the price you send is without VAT, and you must send a minimum and a maximum alongside it. Get either wrong and the offer doesn't go live. Here's exactly what eMAG expects, what breaks when it's off, and how MEGZO maps a VAT-inclusive ERP price into something eMAG accepts.
The sale price is ex-VAT, not the shelf price
The sale price field on an eMAG offer excludes VAT. eMAG applies the VAT rate itself and shows the gross price to the buyer. So if you want a product on the site at 119 RON with 19% VAT, the number you send is 100.00, not 119.
This trips people up because the ERP usually thinks in gross. Your Acumatica item or your eMAG price class often carries a VAT-inclusive figure, because that's what a customer pays at checkout. Send that number raw and your eMAG listing reads 119 plus VAT on the page: same product, wrong shelf price, and you won't notice until a customer does.
The minimum and maximum sale price are required
Every offer must carry a minimum sale price and a maximum sale price, both ex-VAT like the sale price. These aren't optional hints. A publish is rejected if they're missing. They're a guardrail: eMAG, and any automated repricing, won't push your price outside that band. If your computed sale price falls below the minimum or above the maximum, the offer is refused.
The common failure isn't forgetting the fields entirely; it's a band that doesn't bracket the price. You send a sale price of 100 with a floor of 105, and eMAG rejects it because 100 sits below the floor. Or a rounding step nudges the price just past the ceiling. Both look like mysterious publish errors until you line up the three numbers.
How MEGZO maps an ERP price to eMAG
MEGZO treats this as a mapping problem, not a hardcoded rule. The price flow runs through per-field mapping you control, so the VAT math and the guards are configuration, not a black box:
- De-VAT the source price. Take the ERP price and divide by (1 + VAT rate) to get ex-VAT. The rate comes from the channel's VAT table that eMAG exposes, so you're not hand-typing 19% in five places.
- Round deliberately. Dividing by 1.19 rarely lands clean. MEGZO rounds to the channel's precision as an explicit transform; you decide the rule and preview the result before it ships, instead of inheriting whatever floating-point gives you.
- Set the min and max guards. Derive the minimum and maximum sale price from your rule, a fixed floor and ceiling or a margin band around the computed price, and the engine guarantees the band actually brackets the sale price before it sends. No more below-floor rejections from a stale band.
- Preview against a real record. Before a mapping goes live you run it against a sample item and see the exact ex-VAT price, minimum, and maximum eMAG will receive. The math is visible, so a wrong VAT rate is caught at config time, not after a few hundred mispriced listings.
Why this lives next to oversell and order rules
Pricing is one flow among several MEGZO runs on a 5-minute pull heartbeat, plus webhook wake-ups where eMAG supports them. The same engine that de-VATs your price also publishes stock as max(0, available − buffer) so the last unit isn't sold twice, and turns each eMAG order into exactly one ERP Sales Order, never two, even on a retry. Your ERP stays the source of truth; MEGZO is the thin sync layer translating between it and the channel.
That's the architectural difference from running everything inside BaseLinker, where the data hub lives in BaseLinker. With MEGZO the ERP keeps the master record and you own the field mapping, including this VAT math, end to end. If you're moving off an existing setup, it's a migration, not a rebuild.
MEGZO Integrator Vortex is a managed, per-tenant service, Romania-first and expanding across CEE. See all integrations or get started.