{"id":148,"date":"2026-10-27T09:00:00","date_gmt":"2026-10-27T08:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=148"},"modified":"2026-10-27T09:00:00","modified_gmt":"2026-10-27T08:00:00","slug":"mollie-settlement-order-matching","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/reliably-linking-mollie-settlements-to-online-store-orders\/","title":{"rendered":"Reliably linking Mollie settlements to online store orders"},"content":{"rendered":"

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.<\/p>\n

Why a payout is not one order<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Matching sequence and evidence level<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Step<\/th>\nSignal<\/th>\nEvidence level<\/th>\nAction on conflict<\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\nExact Mollie payment\/order ID<\/td>\nHigh<\/td>\nCheck duplicate identity<\/td>\n<\/tr>\n
2<\/td>\nValidated metadata with shop and order<\/td>\nHigh after scope verification<\/td>\nDo not search outside the workspace<\/td>\n<\/tr>\n
3<\/td>\nKnown AFAS or online store reference<\/td>\nMedium<\/td>\nCompare lifecycle and content<\/td>\n<\/tr>\n
4<\/td>\nBounded description fallback<\/td>\nLayer<\/td>\nHuman review<\/td>\n<\/tr>\n
No match<\/td>\nAmount\/date only<\/td>\nInsufficient<\/td>\nLeave unmatched<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

This is technical reconciliation, not accounting advice. Have an authorised finance lead determine ledger choices and processing. The integration layer in Connect<\/a> can retain identities and outcomes in a traceable way.<\/p>\n

Fictional example: refund in the next settlement<\/h2>\n

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.<\/p>\n

The same settlement contains a POS line without a payment ID, with only \u201cATLAS 904\u201d 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.<\/p>\n

Month-end closing check<\/h2>\n