Marketplace Settlement Reconciliation

Marketplace payouts almost never equal the revenue you invoiced. A single deposit landing in your bank account is a net number: gross order value, less referral and closing fees, less fulfilment, storage and shipping charges, less advertising billed against the same seller account, less refunds and returns processed inside the period, plus or minus a rolling reserve the marketplace holds back against future claims. Finance teams running Dynamics 365 Finance and Supply Chain Management usually rebuild that arithmetic in a spreadsheet every settlement cycle, then post one summary journal that nobody can trace back to an order. When the bank account does not agree at month end, the cause is almost always a fee type that was never mapped to a main account, a refund posted in a different period than the original invoice, or a reserve that was treated as lost cash.

This app closes that loop inside F&O. ECOSIRE builds it for you as an X++ extension package — extension classes, event handlers and Chain of Command only, with no overlayering of standard objects — so a settlement report becomes a first-class financial document with its own number sequence, its own reconciliation status, and a drill path that runs from the bank statement line, to the deposit, to the settlement line, to the sales order and invoice behind it.

Nothing here is pre-built or downloadable. Each build is scoped to the marketplaces you actually sell on, the report formats they give you, and your chart of accounts and dimension structure. Typical lead time is two to four weeks from signed quote.

Settlement ingestion

Settlement reports arrive as flat files, as portal downloads, or over the marketplace API. We build a composite data entity so the report can be loaded through the Data management framework by hand, dropped into a recurring data job for unattended import, or pushed over OData by middleware you already run. Header and line data land in dedicated tables with their own number sequence registered through NumberSeqApplicationModule, so every import is an addressable document rather than a batch of orphan journal lines. Re-importing the same report is safe: rows are keyed on the marketplace settlement identifier and duplicates are rejected rather than double-posted.

Fee, deduction and adjustment mapping

The heart of the app is a mapping table that resolves each transaction type on the report — referral fee, closing fee, fulfilment fee, storage, advertising, promotional rebate, shipping credit, tax withheld, adjustment — to a main account and a complete financial dimension combination. Mapping is maintained per legal entity, so a group running several selling entities in different countries does not share one compromise chart. Unmapped types do not silently fall into a suspense account: the line is held, the reconciliation is flagged, and an exception appears in the workspace until a finance user maps it.

Posting runs through LedgerJournalTable and LedgerJournalTrans and is committed with the standard LedgerJournalCheckPost class, which means account structures, dimension rules, posting restrictions and period status are all validated exactly as they would be for a hand-keyed journal.

Cash application and bank matching

Where the settlement report identifies the orders it is paying for, the app generates a customer payment journal and settles the open CustTrans records by invoice reference using standard settlement, so customer ageing, CustSettlement history and any cash discount logic stay correct. Where the marketplace pays in bulk without invoice-level detail, the deposit posts against a clearing account and the app applies the allocation rule you choose.

The bank side matters as much as the ledger side. Deposits are written with a matching reference so the net payout clears against the imported bank statement through advanced bank reconciliation matching rules, instead of a person ticking numbers by eye.

Reserves, refunds and chargebacks

A rolling reserve is not an expense. The app posts withheld amounts to a dedicated balance sheet account, tracks the reserve balance per marketplace and per legal entity, and reverses it automatically when the funds are released in a later settlement. Refunds, returns and chargebacks are matched back to the original SalesTable and CustInvoiceJour records where the reference exists, and posted as credit notes or negative payments according to the rule agreed during scoping — so returned revenue reverses against the period and the account it originally hit.

Multi-entity, multi-currency, unattended

Everything is legal-entity aware. A settlement in one company never posts into another, and cross-company reporting happens in the workspace rather than by mixing DataAreaId. Payouts in a currency other than the accounting currency use a configurable exchange rate type, and realized exchange differences post to the accounts you nominate.

Ingestion, posting and matching run as a SysOperation batch job with its own batch group and recurrence, with retry on transient failure and an alert when a run ends with unresolved exceptions. A reconciliation workspace gives finance the tiles that matter: unmatched settlement lines, ageing of open items, reserves outstanding, and deposits not yet cleared on the bank.

Who this is for

Sellers and brands moving volume through one or more online marketplaces and accounting for it in Dynamics 365 Finance and Supply Chain Management. It is most valuable when settlement cycles are frequent, fee structures are complicated, several legal entities or currencies are in play, or when an audit has already raised a finding about unsupported manual journals. It is not aimed at a business posting a single monthly summary entry for a marketplace that is immaterial to the accounts.

How delivery works

1. Scoping call. We review the marketplaces in scope, sample settlement reports, your chart of accounts and dimension structure, your bank reconciliation approach, and your environment topology and version. 2. Fixed quote. You get a written scope — entities, mappings, posting rules, batch design, security — and a fixed price and delivery date against it. The listed price reflects a baseline scope; a build covering several marketplaces or unusual posting rules is quoted accordingly. 3. Build. Development happens in our environment against your target application and platform version, in a model that carries no overlayering, with source committed to a branch we hand to your Azure DevOps repository. 4. Install in test. We deliver a deployable package that is applied to your sandbox through your usual LCS release pipeline. We configure the mappings with you, load real settlement reports, and reconcile a full period end to end before anyone talks about production. 5. Production. The same package moves to production on your release cadence. Nothing is pushed to a production environment without your sign-off. 6. Support. A defect-fix warranty window follows go-live, and a longer support arrangement is available where you want us to keep pace with marketplace report changes and service updates.