Link a Mollie settlement line to an online store order using a fixed matching sequence: direct payment identity first, then verified metadata and, last, a bounded description fallback. Amount and date alone are insufficient. A settlement contains payments, refunds, captures, fees and chargebacks, each of which may have a different financial meaning.
Why a payout is not one order
Mollie combines several transactions into settlements. The bank sees one payout, while finance needs to know which online store order and AFAS entry each underlying payment or correction belongs to. A refund may also occur in a later month than the original sale. Matching must follow the transaction lifecycle rather than simply compare the payout amount with daily revenue.
Retain payment IDs throughout the order chain from checkout onwards. When settlement data arrives later, that identity is the strongest link. Metadata such as order number and shop provides a second route, provided it is validated within the same workspace. A description may help with older or POS transactions, but warrants lower confidence and visible review.
Matching sequence and evidence level
| Step | Signal | Evidence level | Action on conflict |
|---|---|---|---|
| 1 | Exact Mollie payment/order ID | High | Check duplicate identity |
| 2 | Validated metadata with shop and order | High after scope verification | Do not search outside the workspace |
| 3 | Known AFAS or online store reference | Medium | Compare lifecycle and content |
| 4 | Bounded description fallback | Layer | Human review |
| No match | Amount/date only | Insufficient | Leave unmatched |
This is technical reconciliation, not accounting advice. Have an authorised finance lead determine ledger choices and processing. The integration layer in Connect can retain identities and outcomes in a traceable way.
Fictional example: refund in the next settlement
Fictional example: online shop Atlas Thee receives payment `tr_A` for order AT-901. The payment ID is stored against the order. Two weeks later, the customer receives a partial refund appearing in a different settlement. The matcher links both payment and refund to AT-901 through the same verified lifecycle, while retaining their transaction types and amounts separately.
The same settlement contains a POS line without a payment ID, with only “ATLAS 904” in its description. Both order AT-904 and an older invoice 904 exist. The fallback produces no unique, strong match and creates a review task instead of automatically posting it. This fictional example shows why a convincing amount is not an identity.
Month-end closing check
- Are all settlement lines classified by type: payment, refund, capture, fee or chargeback?
- Does every automatic match have a traceable identity and workspace?
- Are low-confidence matches separate from confirmed matches?
- Are late refunds and credits tracked across month boundaries?
- Can an uncertain financial write be verified in AFAS before retrying?
- Is an unmatched line visible with an owner and next check?
Have Desk show the relevant payment and refund status for an order, while restricting sensitive financial details by role. The technical relationship with the online store and ERP is explained further in WooCommerce and AFAS.
Make reconciliation repeatable. A settlement may be imported before all related refunds, credit notes or AFAS invoices are visible. Retain source lines unchanged and recalculate the current matching status without replacing previously confirmed identities. Distinguish “not yet available” from “substantively different”. A late invoice can resolve a temporary open item; a different net amount requires actual investigation. Use a reference date and show when each source was last refreshed successfully.
Check one-to-many relationships too. An order may have several captures or refunds, while a settlement line may represent a fee component that does not belong to exactly one order. Do not force that fee into an order match to make the report look complete. Report for each category what is matched exactly, matched provisionally, accounted for collectively or unmatched. For manual matching, record the chosen source identity and reason. The next monthly run can then respect the decision, and an auditor can navigate from an AFAS record back to the payment and online store order.
Make corrections reversible. If an employee later finds a match incorrect, unlink the relationship with an audit reason while retaining the original settlement line. Recalculate dependent reports in a controlled way. Never overwrite the source record to produce the desired balance; doing so removes the evidence needed to understand the error.
Want to link settlement lines to demonstrable order identities? Have Yindle define your matching sequence and exceptions.