MPH WMSPayouts
How payouts from Shopify Payments are matched to orders and booked, and the two ways to mark an invoice as paid
A sale books money into a receivable: the payment provider owes you. A payout clears it. Without payout reconciliation the receivable grows forever and never ties out to the bank statement.
A payout is booked as one voucher:
| Bank | up by the net that actually arrived |
| Fee account | up by the provider's fees |
| Clearing account | down by the gross of the charges |
Gross charges, less the provider's fees, equals what reached the bank. The clearing account goes to zero per payout.
Where payouts come from
Shopify Payments is the supported source today. MPH reads payouts with the store's own connection, so there is no separate login. The store must have granted access to payouts; a store connected before that permission existed shows a warning under Finance → Payouts and needs to be reconnected once.
Payouts are fetched every morning at 06:30, with every transaction behind them: charges, refunds, disputes and fees. Sync payouts now on the Payouts page fetches them on demand.
Setting up
Under Finance → Payouts, each payout source has a mapping:
| Setting | Meaning |
|---|---|
| Bank account | Where the net lands. |
| Clearing account | The receivable the sale was booked to, for example 1580. |
| Fee account | Where the provider's fees go. |
| Pay each invoice when the payout arrives | See Two ways to mark an invoice as paid. |
A source with no mapping holds its payouts rather than posting to a guessed account.
Matching
Every transaction in a payout is matched to its order, first by the gateway transaction, then by the channel's order id and order number. Open a payout to see how many matched, and to fix the rest by hand:
- Match to order for a charge the automatic match could not place.
- No order for a platform fee or a balance transfer, which never had an order.
- Re-match after an order that was missing has been imported.
A payout whose transactions do not sum to its total is never posted, whatever the mapping says. The difference is shown on the payout.
Statuses
| Status | Meaning |
|---|---|
| Waiting | Fetched, not yet posted. |
| Missing accounts | The source has no mapping yet. Add one. |
| Unmatched charges | A charge has no order. Match it, or mark it as having none. |
| Invoice not sent | An order's invoice has not reached the ledger yet. The payout waits for it. |
| Refund not credited | A refund in the payout has no credit note yet. The payout waits for it. |
| Posted | Booked in the ledger. |
| Send failed | The ledger rejected it. The error is shown on the payout; fix the cause and press Retry. |
| Reversed | The provider cancelled or failed the payout. The money did not move, and nothing is booked for it. |
A held payout is held as a whole; it is not posted partially. Held payouts are retried automatically on the next sync, so fixing the cause is usually enough. Retry on the payout does it straight away.
A sent payout is frozen. If the provider later restates its figures, MPH reports the difference rather than silently rewriting a payout that a posted voucher was built from. A reversal after posting needs a reversing voucher written by hand.
Two ways to mark an invoice as paid
For a provider that pays you in batches, the invoice can be marked as paid at two different moments. The ledger gets the same totals either way. What differs is when each invoice says it was paid, and how much the payout has to wait for.
At invoice time
Turn on Mark as paid for the payment method under Settings → Accounting → Payment methods, with the clearing account as its payment account.
- The invoice is sent and marked paid on the same day, against the clearing account. The receivable disappears when the invoice is created.
- The payout is fetched and booked as above. The clearing account nets to zero.
Every invoice shows as paid on its invoice date, not the day the money came. To see which payout covered a given order you look at the payout in MPH, where the match is, not in the ledger. In return, payouts rarely wait: they do not depend on the invoice having reached the ledger first.
When the payout arrives
Turn on Pay each invoice when the payout arrives on the payout mapping, and leave Mark as paid off for that payment method.
- The invoice is sent and left open in the ledger.
- When the payout arrives, each matched order's invoice is paid on the payout date against the clearing account. Then the payout voucher is booked as above.
- Refunds are handled from the other side: an order's credit note is sent and paid when the payout that carries the refund arrives, because the payout is the proof the money actually went back. Disputes stay in the voucher.
Every invoice in the ledger says which day its money actually came. The cost is that a payout waits until every invoice it covers has reached the ledger, and until every refund in it has a credit note.
Pick one
Do not turn on both for the same payment method. If Mark as paid is on, the payout finds every invoice already paid. The ledger treats the second payment as a no-op rather than a double payment, so nothing is booked twice, but the setting does nothing. The payout mapping warns when this applies.
Whichever you pick, the payment account on the payment method and the clearing account on the payout mapping must be the same account. If they differ, one account grows forever and the other is never emptied, and nothing warns about it.
Switching from one to the other is safe for payouts: they are fetched and booked the same way in both modes. Only the date on which each invoice is marked paid changes, from the switch onwards.