Card Payments & Payout Reconciliation

The pain

Your gateway pays you in batches. Your customers pay you one order at a time. Between those two facts sits the work nobody wants: opening the payout report, ticking off which of the 300 charges in a batch belong to which Customer Payment, hunting the difference caused by processing fees, then repeating the exercise for refunds, partial refunds, disputes, dispute reversals and the monthly platform invoice.

In NetSuite this normally surfaces as an Undeposited Funds account that only grows, a bank account whose statement lines never quite equal the Deposit records, and a controller who closes three days late because the card clearing account has an unexplained balance. The gateway's own dashboard is not an accounting system — it reports gross activity in the gateway's own timezone and currency, while NetSuite needs net cash on a Deposit, fees on an expense account, and every disputed transaction reversed against the right customer.

What ECOSIRE builds

This is not a shelf product. ECOSIRE builds a NetSuite customization for your account, against your chart of accounts, your subsidiaries and your gateway configuration. The work is delivered as an SDF project / unmanaged bundle that you own outright.

Payout ingestion

A Scheduled Script polls the gateway's payout and balance-transaction endpoints on a cadence you choose and writes each payout to a custom record (for example customrecord_eco_gw_payout) with its own child transaction lines (customrecord_eco_gw_payout_line). Every line carries the gateway charge id, the gross amount, the fee, the net, the currency, the object type (charge, refund, dispute, dispute reversal, adjustment, transfer) and the arrival date. Nothing posts yet — ingestion and posting are deliberately separate so a bad API day never leaves half a journal behind.

Matching engine

A Map/Reduce script walks unmatched payout lines and resolves each one to a NetSuite transaction. The matcher runs a configurable ladder of strategies: exact match on a gateway charge id stored in a custom transaction body field on the Sales Order or Customer Payment, match on the externalid your storefront wrote, match on order number carried in the gateway metadata, then a tolerance-based match on amount plus customer plus date window. Each attempt is recorded on the payout line with the strategy that won and a confidence value, so a reviewer can see why something matched rather than trusting a black box.

Posting

For a fully matched payout the app creates one Deposit whose lines are the individual Customer Payments (or Cash Sales) in that batch, plus an Other Deposit line for the negative fee total coded to your processing-fee expense account and department/class/location or custom segment defaults. Net cash on the Deposit equals the exact amount that hits your bank, which is the entire point — the bank statement line then matches a single NetSuite record instead of 300.

Refunds, chargebacks and disputes

Refund lines create or match a Customer Refund against the original Customer Payment. Dispute lines post a chargeback: configurable as a Journal Entry to a disputes-held account or as a Customer Refund plus fee, depending on how your auditors want lost disputes represented. Dispute reversals (you won) reverse the original posting and re-apply the payment. Every dispute keeps its gateway reason code and evidence-due date on the custom record so the team chasing evidence works from NetSuite, not from a browser tab.

Exceptions instead of silence

Anything the matcher cannot resolve lands on an exception queue — a saved search driven Suitelet where a user sees the payout line, the candidate NetSuite transactions the matcher considered, and one-click actions to accept a candidate, split across several payments, or write off within a threshold. A SuiteFlow workflow escalates lines older than N days to a role you nominate. Nothing is auto-written-off without a rule you approved during scoping.

Multi-subsidiary and multi-currency

If you run OneWorld, each gateway account maps to a subsidiary and each payout maps to that subsidiary's bank account and processing-fee account. Payouts settled in a currency other than the subsidiary base currency post with the gateway's own conversion figures where the API supplies them, and the residual difference goes to a realised gain/loss account you nominate — not silently into fees.

Who this is for

Direct-to-consumer and B2B sellers taking card payments through a gateway into NetSuite, especially anyone whose Undeposited Funds balance no longer reconciles, anyone running more than one gateway account or more than one subsidiary, and finance teams whose close is gated on card clearing.

How delivery works

1. Scoping call. We walk your gateway setup, your accounts, your existing order-to-cash flow, and how orders currently reach NetSuite. We agree what a matched payout must post to. 2. Fixed quote. You receive a written scope with the record model, the posting rules, the exception rules and a fixed price. No hourly drift. 3. Build. ECOSIRE builds it as an SDF project — SuiteScript 2.1 Scheduled, Map/Reduce, User Event and RESTlet scripts, custom records, custom transaction body fields, saved searches, roles and a SuiteFlow escalation. 4. Install in your sandbox. Deployed to your sandbox or a Release Preview account first, run against your real payout history so you can compare its output to the reconciliation you did by hand. 5. Production. After you sign off on sandbox output, we deploy the same bundle to production and run a supervised first close with you. 6. Support window. A defined post-go-live support period for defects and gateway API changes, with the source in your account so any developer can maintain it later.

Lead time is typically one working week from signed quote, depending on how many gateways, subsidiaries and dispute behaviours are in scope.