Marketplace Settlement & Fee Reconciliation

The problem

A marketplace settlement report is not a payout figure. It is a ledger of everything that happened in the period: order revenue, shipping charged to the buyer, gift-wrap, promotional rebates, referral fees, fulfillment fees, storage fees, long-term storage surcharges, advertising, refunds, refund commission credits, chargebacks, reimbursements, subscription fees, and adjustments the marketplace does not always explain. Dozens of distinct fee types, and the net of all of it hits your bank account as one number.

Most finance teams handle this by downloading the report, pivoting it in a spreadsheet, and hand-keying a journal entry each period. The consequences are predictable. Gross revenue is understated because the fees were netted out before the journal was written. Fees land in a single catch-all expense account, so nobody can tell what fulfillment actually costs versus advertising. The bank reconciliation never quite ties, so someone posts a plug. Month-end takes days longer than it should. And when the marketplace introduces a new fee type mid-quarter, the spreadsheet silently drops it into the wrong bucket.

What ECOSIRE builds

We build a NetSuite customization that ingests settlement reports, maps every line to accounting you have defined, and posts journal entries that balance to the payout — with the mapping visible and maintainable by your accountants rather than buried in code.

A mapping table your finance team owns

The centrepiece is a custom record, customrecord_eco_settlement_map, holding one row per fee type per marketplace per subsidiary. Each row carries the marketplace's own transaction and amount-type identifiers, the target GL account, an optional department, class and location, and an effective date range so a mid-year account change does not rewrite history. Your controller maintains this in the NetSuite UI. No script edit is needed to add a fee type or move one account.

Critically, the design fails loudly. When a settlement line arrives with a combination that has no active mapping row, the script does not guess and does not silently sweep it into a default account. It posts the batch to a suspense account you nominate, flags the line, and raises an alert so someone maps it deliberately.

Ingestion and parsing

A Scheduled script retrieves finished settlement reports from the marketplace API on a cadence you set, or accepts a file dropped into the File Cabinet if you prefer manual control during rollout. A Map/Reduce script parses the report, groups lines by settlement ID, and stages them on a settlement header and line custom record pair. Reports run large, so parsing is chunked through Map/Reduce stages to stay within governance limits rather than timing out on a single Scheduled script.

Each settlement header stores the marketplace, the settlement ID, the period start and end, the deposit date, the marketplace's stated net, the currency and the computed total from the lines. If those two totals disagree, the settlement is held and flagged rather than posted.

Journal posting that ties to the bank

Once a settlement is parsed, balanced and fully mapped, the script creates a journal entry summarising the period by GL account, with the net debited to the clearing account you use for that marketplace's deposits. When the deposit lands, the clearing account balance is the deposit amount, so bank reconciliation is a match rather than an investigation.

Where you need order-level attribution rather than a period summary, we can post at order granularity or apply settlement lines against existing NetSuite transactions — the trade-off between ledger volume and traceability is a scoping decision, and we build what you choose.

Multi-currency and OneWorld

For accounts settling in more than one currency, the journal is posted in the settlement currency against the correct subsidiary, with the exchange rate taken from the rate you nominate — NetSuite's rate on the deposit date, the marketplace's stated rate, or a rate type of your choosing. Realised FX difference is posted to the account you specify rather than absorbed into fee expense.

Reporting your accountants will actually use

We deliver saved searches and a settlement dashboard covering fee expense by type and period, unmapped lines awaiting attention, settlements held for imbalance, refunds and reimbursements by reason, and a clearing-account aging so anything stuck is visible. Because fees land in distinct accounts, contribution margin per marketplace becomes a real report instead of an estimate.

Who this is for

Finance teams closing books on NetSuite with meaningful marketplace revenue — typically anyone whose settlement journal is currently hand-keyed, whose fee expense sits in one account, or whose marketplace clearing balance never quite reaches zero. It is equally relevant to a single-entity seller with one marketplace and to a OneWorld group settling in several currencies across subsidiaries.

How delivery works

Scoping call. We review a real settlement report from your account, your chart of accounts, your clearing and suspense accounts, your subsidiary and currency setup, and whether you need summary or order-level posting. We agree the initial mapping rows together.

Fixed quote. You receive a written scope, the object list, price and delivery window before development begins. Lead time is typically one working week from acceptance.

Build. We develop as an SDF project using SuiteScript 2.1, with marketplace credentials held in NetSuite's secrets management.

Install in sandbox. We deploy to your sandbox, load several real historical settlement periods, and post them alongside your existing manual journals so you can compare line by line before trusting it.

Install in production. We deploy the bundle, load the agreed mapping, configure roles and script schedules, and run the first live settlement with your finance team present.

Support. A support window is included from go-live covering defects, new fee types appearing within the delivered scope, and questions from your team. You own the code and the SDF project.