Amazon Marketplace Connector

Amazon volume creates a very specific kind of accounting mess. Orders arrive in Seller Central with their own numbering, their own tax treatment, their own promotion and shipping components, and their own settlement cycle. SAP Business One needs a Business Partner, a Sales Order, a delivery, an A/R Invoice and a Journal Entry for each of them. Most teams bridge that gap by hand — a daily CSV export, a spreadsheet mapping ASINs to item codes, an import that quietly creates duplicate Business Partners, and a month end where the deposit Amazon actually paid does not match the sum of the invoices it was supposed to cover.

The expensive part is not the typing. It is the drift: stock oversold because the Amazon quantity was last refreshed yesterday, refunds issued on the marketplace that never became Credit Memos in SAP, referral and fulfilment fees parked in a suspense account because nobody wants to split a settlement report line by line, and an unshipped order aging that exists only in one person's head.

What ECOSIRE builds

This is a SAP Business One add-on, not a separate platform you have to host and babysit. Marketplace traffic runs over the Amazon Selling Partner API (SP-API) using your own seller application registration. Everything written into SAP goes through the Service Layer (REST/OData) where the object is properly supported, and drops to the DI API for the operations the Service Layer does not expose cleanly. Configuration, mapping tables and the sync ledger are User-Defined Objects (UDOs) and User-Defined Tables (UDTs) inside your company database, so they sit inside your existing backup, your authorisation groups and your upgrade path. There is no external database holding your channel state hostage.

Order ingestion and Business Partner handling

The add-on polls SP-API for new and updated orders on a schedule you set per marketplace and creates a Sales Order for each one. The Amazon order id, marketplace id, fulfilment channel, pseudonymised buyer identifier and requested ship-by date are written to User-Defined Fields on the order header; the marketplace SKU stays on the line. The order-id UDF carries a unique index, which is the single most important design decision in the connector: a re-poll, a retry after a timeout, or two application servers running the job at once cannot produce a second Sales Order for the same marketplace order.

You choose the Business Partner model during scoping. Most sellers use one control Business Partner per marketplace, with buyer name and ship-to address written to the document address block — that keeps the BP master clean and matches how the settlement money actually arrives. If you need per-buyer analysis instead, Business Partners are created on demand under a numbering series you nominate, deduplicated on the buyer identifier.

Items, ASINs and pricing

Marketplace SKUs and ASINs map to SAP ItemCodes in a User-Defined Table, maintained through a proper UDO form rather than a text file, with per-marketplace price lists and unit-of-measure conversion for multipacks. An order containing an unmapped SKU is not silently dropped and does not fail the whole batch: it is quarantined with a clear reason, surfaced in the monitor, and replayed once you add the mapping.

Inventory and FBA

Available quantity is published back to Amazon from the Warehouses you nominate, with an optional buffer per marketplace so you never sell the last unit of a shared item. FBA is modelled the way SAP expects it: a dedicated Warehouse, with Inventory Transfer documents representing shipments into fulfilment centres, so FBA stock stays visible in inventory valuation and reorder logic instead of vanishing from the ledger the moment it leaves the building. FBA inventory positions are pulled back, so discrepancies between what SAP thinks is at Amazon and what Amazon reports become visible rather than being discovered at stocktake.

Fulfilment writeback for FBM

For merchant-fulfilled orders, posting a Delivery in SAP is the trigger: shipment is confirmed to Amazon with the carrier, service and tracking number taken from the delivery document, so your team works in one system and the marketplace stays accurate without a second data-entry pass.

Invoicing, tax and settlement reconciliation

A/R Invoices are generated per order or consolidated per settlement period, whichever your finance team prefers, with tax codes resolved per marketplace and ship-to jurisdiction using the determination rules agreed in scoping. Then the part that usually gets skipped: each settlement report is ingested and decomposed — principal, shipping, gift wrap, promotional rebates, referral fees, fulfilment and storage fees, refunds, chargebacks, reserves and adjustments — and posted as Journal Entries against the GL accounts you nominate, with an incoming payment that reconciles to the disbursement your bank actually received. What is left is the reserve balance, not a mystery.

Returns, refunds and credit memos

Marketplace refunds and returns create Returns documents and Credit Memos against the originating invoice, restocking to the warehouse or to a quarantine location depending on disposition. Credit Memos above a value you set can be routed through a standard SAP approval procedure, so nothing reduces revenue without the authorisation your auditors expect.

Controls, audit and recovery

Every SP-API call and every SAP document write is logged in a UDT with the request, the response, the resulting document key and the duration. Failures enter a retry queue with backoff and an email alert; SP-API throttling is respected rather than fought. Because the log holds document keys, any figure the connector produced can be traced from the Journal Entry back to the marketplace line that caused it.

Reporting

Crystal Reports layouts are delivered for the questions this integration creates: a settlement-to-GL bridge, unshipped order aging by marketplace, per-ASIN fee and margin contribution, and a sync exception list.

Who this is for

Sellers running Amazon alongside other channels with SAP Business One as the book of record, typically past the point where one person can reconcile a settlement by hand: multi-marketplace sellers, brands running a mixed FBA and FBM footprint, distributors listing a subset of their catalogue, and finance teams who have been asked to explain the gap between marketplace revenue and posted revenue.

How delivery works

Nothing here is pre-built and there is no download. The sequence is:

1. Scoping call. We walk your Seller Central setup, marketplaces, fulfilment mix, tax treatment, chart of accounts and warehouse structure, and agree the Business Partner and invoicing model. 2. Fixed quote. You get a written scope and a fixed price before any build starts. The list price is the starting point for a single-marketplace, single-company-database build; additional marketplaces, multi-company consolidation, unusual tax determination or non-standard fulfilment flows are priced explicitly rather than discovered later. 3. Build. Typically one working week, run against a copy of your test company database wherever you can provide one, because mapping problems only surface against a real item master. 4. Install into test. The add-on and its database objects are installed into your test company and we run a joint UAT script end to end: order pulled, delivery posted, shipment confirmed, invoice created, settlement ingested, refund credited. 5. Production install. Cutover with the mapping tables loaded, a documented rollback, and an agreed first-settlement checkpoint. 6. Support window. A post-go-live support window with defect fixes at no charge, and the source code in your hands.

What we do not claim

There is no free trial and no instant download, because there is no shelf copy. ECOSIRE does not resell marketplace access: you keep your own Amazon Seller Central account and authorise our application against it, revocable at any time. Marketplace rate limits, report availability windows and API behaviour are Amazon's, and the design respects them rather than pretending they do not exist. We are not an SAP partner or certified reseller and make no claim to be — this is add-on development against documented, publicly available SAP Business One extensibility interfaces.