Marketplace Invoicing Integration: Order to Invoice
How a marketplace order becomes an invoice in your own ERP or e-invoicing system, which order fields must be correct, and how to set up the flow safely.
The invoice for a marketplace order is issued by the seller, not by the marketplace. The integration's job is to carry the order into your ERP with the right data; the invoice itself is generated in your ERP or in the e-invoicing system connected to it, with your own numbering and format. So "marketplace invoicing integration" is really about the quality of order transfer: if customer details, line items, amounts, tax, shipping and payment reach the ERP complete and correct, invoicing is painless. This guide follows the path from order to invoice, the fields that fail most often, and the setup sequence.
Who invoices, and what the integration does
This distinction needs settling first, because many sellers expect the integration to invoice. Invoicing is an accounting function: document type, numbering series, archiving and filing are a setup agreed between the business, its accountant and its ERP. An integration that reaches into that setup is both unnecessary and risky.
The integration's job is transport. An order from Amazon, eBay, Walmart or Trendyol is written into the ERP as an order record with its customer, line items, amounts, carrier and payment details. The ERP sees the record and the invoice is issued from there under the business's own rules. The invoice number and status flow back to the integration and appear on the order screen.
The benefit is that your accounting does not change. If you invoice from SAP today, you invoice from SAP tomorrow; the integration simply delivers a complete order. Which document type applies depends on the buyer and on rules that change; your ERP and your accountant make that call.
From order to invoice: the data flow
These fields travel when an order becomes an invoice. If any of them is missing or wrong, the invoice is either blocked or issued incorrectly.
- Customer details. Name, address and, where relevant, tax or company identifier. Marketplaces supply these in different shapes; the integration normalises them.
- Line items. SKU, barcode, quantity and unit price per line. A wrong SKU match invoices the wrong product.
- Amounts. Item price, marketplace-funded discounts, coupons, shipping charge. The invoice total must equal what the customer paid.
- Tax. Rate and amount per item. Items with different tax rates can share one order.
- Shipping and payment. Carrier, tracking number, payment method. How the shipping charge is shown on the invoice is defined in the ERP.
- Marketplace order number. The key that links the invoice to the marketplace order and is used in settlement reconciliation.
How these fields are written per ERP is described in Nebim V3 marketplace integration and Logo, Mikro and SAP ERP integration.
Where invoices go wrong
The invoicing problems seen most often in the field come from incomplete order data. Discounts and coupons top the list. The marketplace applies its own coupon and the customer pays less, but some marketplaces expect the seller's invoice at the pre-coupon amount and others at the post-coupon amount. The integration must know, per channel, which amount goes on the invoice; a wrong setting produces a mismatch on every order.
Shipping charges come second. If the customer paid for shipping, is it a separate invoice line or part of the item price? That must be defined in the ERP, and the integration must carry the charge as its own field.
Customer data comes third. A business buyer entered a tax identifier, the marketplace supplied it in a separate field, and the integration did not pick it up, so the invoice is issued with the wrong document type. Fourth is SKU matching; if product matching by SKU and barcode is off, the invoice names the wrong product. Fifth is duplication: an order written to the ERP twice produces two invoices. The integration must use the marketplace order number as a unique key and refuse to write it a second time.
Returns, cancellations and reconciliation
After invoicing, an order can be cancelled or returned. A cancellation before invoicing cancels the ERP order and no invoice is issued. A return after invoicing opens a return movement in the ERP and the credit document is created in your own accounting setup. The integration matches the return to the marketplace order number, so the affected invoice is clear.
That match matters at month end. The marketplace settlement report arrives per order and is compared with the invoices and returns in the ERP. Missing payouts, returns whose commission was not refunded and orders that net negative surface in that comparison. If the order number is identical on the invoice and the settlement line, matching takes minutes; if not, days. See settlement and commission reconciliation.
Cross-border orders add a layer: the invoice is issued in a foreign currency and export paperwork is attached to the order. That flow is covered in micro-export order flow.
Setup sequence and shadow mode
The sequence we recommend for building the invoicing flow:
- Settle order and invoice rules in the ERP. How is shipping shown, which discount amount is written, which numbering series is used?
- Connect channels and complete SKU matching. A wrong match is a wrong invoice.
- Run shadow mode. For one to two weeks the system reads orders but does not write to the ERP. Compare amounts, tax and customer fields of incoming orders against the invoices you issue by hand.
- Enable ERP writes on one channel. Start with the lowest-volume channel and check the first invoices one by one.
- Hand over channel by channel. Each channel's amount logic may differ; verify the first orders on each.
- Test reconciliation. Compare the first settlement report with the ERP invoices.
Shadow mode is the most valuable step here; details in shadow-mode integration testing.
How it works with Bulutegra
Bulutegra writes orders from more than 24 marketplaces into your ERP (Nebim V3, Logo, Mikro, SAP) automatically, with customer, line items, amounts, tax details, carrier and payment method. Bulutegra does not issue the invoice; invoicing and dispatch continue in the business's own ERP and e-invoicing setup. Which amount goes on the invoice is defined per channel during setup, and because the marketplace order number is the unique key, duplicates do not occur. The issued invoice number appears on the order screen; returns and cancellations are posted to the ERP under the same key. A user with the Accounting role sees only order, invoice and settlement screens. Setup starts in shadow mode, and because the software ran against the founding company's own accounting setup first, the flow has been tested in the field. Supported ERPs are listed under Solutions.
To see your orders flow into your ERP with the right data, request a demo.
Frequently asked questions
Who issues the invoice for a marketplace order?
You do; the marketplace does not invoice on the seller's behalf. The order is transferred to your ERP by the integration and the invoice is generated in your ERP or connected e-invoicing system with your own numbering and format. Which document type applies depends on the buyer and on local rules, so ask your accountant.
Does the integration issue invoices?
No. The integration carries the order into the ERP with customer, line items, amounts, tax, shipping and payment details. Your ERP or its e-invoicing provider issues the invoice, so your accounting setup does not change and numbering and archiving stay in your own system.
What happens to the invoice when a marketplace order is returned?
The return is posted to the ERP as a separate movement and the credit note or cancellation is created in your own accounting setup. The integration matches the return to the order by marketplace order number, so it is clear which invoice the return refers to.


