eMAG Payouts: When You Get Paid and How to Read Every Line (2026)

Every eMAG seller asks two finance questions: when does the money arrive and why is the amount not what I expected. The second one is fully answerable with the documents you already hold. The first one is answered by your own contract — this article shows you where to read that answer, and how to settle the second question for good.

1. Where do you read your payment term?

In two places: your seller contract and the payments screen in the eMAG seller panel. The term is set by your contract, which is why we do not copy the single number other guides print. A cash-flow plan built on the wrong term is expensive: you place restock orders against money that has not landed.

The job of this article is not to tell you when the money lands, but to show you how to tell whether the right amount landed. Everything after this point is answerable with the documents you already hold.

2. Does the price you enter on eMAG include VAT?

It does not — and all eMAG reconciliation confusion comes from exactly that fact: the price you enter on eMAG excludes VAT. The API documentation defines the field literally as “sale price without VAT”. What the customer pays is that number plus VAT (in Romania the standard rate is 21%, 11% on books), and that VAT never reaches your pocket.

Hence the classic reconciliation mistake: comparing the bank credit against the total your customers paid. That comparison always looks short, and the gap is not commission — it is the state's VAT. The correct reference is the sum of your ex-VAT prices.

The 15% above is an example, not a rate claim. There is no single “eMAG commission” figure: the rate varies by category and can differ on campaign sales. Read your own rate from your commission invoice — it varies by category. For the pricing plane itself, see commission, VAT and the Buy Button on eMAG.

What does not vary is the plane: eMAG's price field is defined as excluding VAT, and commission is charged on that ex-VAT amount. Only the rate changes. One more rule holds: on a returned order the commission for that sale comes back too — commission is charged on sales that actually happened.

3. What does the eMAG commission invoice contain — and what does it not?

The financial document you can read through eMAG's seller API is the commission invoice. The fields are clear: total excluding VAT, the VAT amount, total including VAT, and a category split in which commission appears as its own category.

What it does not contain forces you to change your reconciliation habits: there is no per-order or per-SKU breakdown. You cannot build the sentence “order X cost me Y in commission” from the invoice. The invoice is a document total. The practical consequence: eMAG reconciliation happens on period totals, not on individual orders.

Compare like with like: if your own calculation is built on ex-VAT amounts, compare it against the invoice's ex-VAT total. Comparing against the VAT-inclusive total invents a deduction that does not exist.

4. How do you reconcile an eMAG month, step by step?

In five steps, about 15 minutes a month: fix the period, sum the ex-VAT base, compute the expected commission, compare it with the invoice's commission category, name the difference.

1. Fix the period. Take the date range the invoice covers and filter your order list to exactly the same range.
2. Build the base. Sum the ex-VAT amounts of that period's sales. That total is the commission base; summing VAT-inclusive amounts inflates it.
3. Compute the expected commission. Single category: base × rate. Read the rate from your commission invoice — it varies by category. Selling across categories: split them — one blended rate will mislead you.
4. Compare with the invoice's commission category. Ex-VAT against ex-VAT.
5. Name the difference. A small gap is usually rounding and period boundaries. A material one has one of the six causes below, and you can name it.

5. Why does the invoice not match the commission you expected?

Almost every material difference comes down to one of these six causes.

• Categories with different rates. A blended-rate calculation on a mixed catalogue never quite matches.
• Campaign sales. A product sold in a campaign can differ from a normal-period sale in both price and commission behaviour.
• Returns and cancellations. On a returned order the commission for that sale comes back too — commission follows the sale that actually happened. Only the timing shifts: is the return deducted from the period in which the sale happened, or from the next one? Put two consecutive periods side by side and you will see it.
• Period-boundary shift. An order placed on the last day of the month can land on the next invoice. Looking at one period it seems short; across two it is correct.
• Service lines beyond commission. Marketplaces typically run separate service fees alongside the sales commission; some per order, some periodic. That is a model difference, not a rate promise — read the line names on your own invoice.
• A price that was never saved. Every eMAG offer has a mandatory minimum and maximum price; a price outside the band is not saved. If your new price never went through, the product sold at the old one and your “expected” base was wrong from the start.

6. What is the mistake that quietly melts your margin?

The most expensive reconciliation error is deducting commission both at line level and again at invoice level. It fails silently: no error appears anywhere, your profit simply looks systematically lower every month, and you make pricing decisions against that wrong number.

This is not a theoretical warning. On the Trendyol side it produced a 5,127.98 RON double count in live data (10 August 2026), and the lesson was written into the eMAG engine from day one — the commission invoice is never counted as a deduction a second time. To see how deduction types are separated from one another, the glossary of deduction types is a good reference.

7. Why is profit on eMAG an estimate?

This has to be said plainly: net profit on eMAG is an estimate. The reason is exactly what section 3 described — with no per-order breakdown on the invoice, a real per-product deduction cannot be derived. Profit is computed from ex-VAT order revenue and the commission rate you enter; if no rate is entered, nothing is invented and the panel shows “—”.

Trendyol and Amazon are different: their settlement data carries the order breakdown, so profit there is computed from real deductions. For the contrast, see how a Trendyol payout is calculated — the line-by-line reconciliation described there has no eMAG equivalent today.

8. Why are the numbers not instant?

eMAG's seller API applies one rate limit shared across all resources: 1 request every 3 seconds, 20 requests per minute. A page returns at most 100 records. So a catalogue of 3,587 products takes roughly 36 requests, about 2 minutes, to sweep. Invalid requests are further capped at 3 per minute and 180 per hour, which rules out aggressive retries.

That limit is the marketplace's contract; no tool can beat it. It is the honest answer to “why did my change not show up instantly”.

9. Can four eMAG countries go into one table?

They cannot: each country is a separate account, a separate currency and a separate reconciliation. eMAG runs the same seller API in Romania, Bulgaria, Hungary and Poland; only the base address and the currency change (RON, BGN, HUF, PLN). Adding four countries into one table is the shortest path to mistaking an FX movement for a deduction.

In Romania the standard VAT rate is 21%, and 11% on books. For the other three countries, read your own rate from your own invoice — each country has its own rate and its own reconciliation. For the multi-channel setup logic, see the multi-marketplace selling strategy.

10. What does Verimle do and not do on eMAG?

It does: compute an estimated profit from orders and the rate you enter; measure your Buy Button rank, the winning price and the number of offers and write them to the panel — you follow your rank there (loss alerts are wired up on Trendyol and Amazon); run margin-protected repricing that never goes below your floor price; pull returns and customer messages into the panel.

It does not: track payouts or settlement statements on eMAG — the per-order breakdown reconciliation needs is not in the seller API, which is why eMAG reconciliation runs on period totals. Deduction disputes are not part of eMAG either: the invoice resource is read-only.

To try your own numbers, start with the eMAG commission calculator, and for the scope of the integration see the eMAG integration page.