Automated Refund Reconciliation System for WooCommerce & Mollie

Refund reconciliation sounds simple until the same transaction has to stay consistent across three systems.

A refund starts in WooCommerce. The actual payment and payout status lives in Mollie. The accounting entries have to be created correctly in e-Boekhouden. Handled manually, every refund means multiple checks, repeated data entry, and constant attention from accounting. Partial refunds, delayed payouts, missing invoices, and duplicated operations make it worse.

I built an automated reconciliation system in n8n made of 11 connected workflows. It takes each refund through the full accounting lifecycle: retrieve the order, find the original invoice, verify the payment with Mollie, create or validate the required accounting entries, confirm the customer actually received the refund, and only then mark the case complete.

The goal

The client needed refunds to stay consistent across WooCommerce, Mollie and e-Boekhouden without someone manually checking each case.

That meant handling:

• standard refunds that should close automatically
• pending payments that need to wait and retry
• partial refunds where the amount or VAT can’t be matched with confidence
• missing orders or invoices that should stop processing and record why
• the risk of the same accounting mutation getting created twice

The key design principle was verification before action. Before creating any accounting mutation, the workflow checks e-Boekhouden itself to see whether that entry already exists. That makes the process safe to rerun and protects against duplicates even if a webhook fires twice or a workflow restarts.

What I built

1. Core refund processor

The main workflow processes one refund at a time through a strict sequence: get the order from WooCommerce, find the invoice in e-Boekhouden, check the payment in Mollie, create the credit note, verify the refund was paid out, and close the accounting entry.

It’s built as a decision tree: every step branches depending on what the system finds. A confirmed payment continues immediately. If a payment is still pending, the case waits and retries later. An ambiguous partial refund gets routed to manual review, and a missing order or invoice stops the process and logs why.

2. Duplicate protection at every mutation

Before creating a payment entry, credit note, or settlement entry, the workflow checks e-Boekhouden directly instead of trusting its own internal status. Each mutation gets a fingerprint built from the refund ID, invoice ID, mutation type, amount including VAT, and currency — so the same refund can pass through the processor multiple times, during retries or after an interruption, without ever creating a second entry.

Refunds are also processed sequentially, one at a time — that removes the risk of two executions racing to create the same mutation.

3. Retry logic and manual review

If Mollie hasn’t confirmed a payment or refund yet, that’s not treated as a failure. The case waits, gets rechecked after six hours, and returns to the queue automatically once the status changes.

Partial refunds get more care. When the refunded amount or VAT can’t be matched confidently to the original invoice, the workflow stops the automatic accounting step and sends the case for manual review instead of guessing. The same logic applies to hard stops: a missing WooCommerce order or accounting invoice halts processing and records the reason until someone resolves it.

4. Independent Mollie audit

The main workflow already validates every refund as it moves through the process, but I wanted a layer of control that doesn’t depend on that same process. A separate audit workflow runs every three hours, pulls the latest refunds directly from Mollie, and compares them against what the reconciliation system already knows.

This matters because if the main workflow fails before recording a refund correctly, checking only its own data would never surface the problem. The audit starts from the external payment provider instead. When something doesn’t match, the case is logged separately for investigation — the audit never touches accounting data itself, keeping verification separate from execution.

5. Monitoring, alerts and reporting

Unexpected workflow errors trigger immediate Telegram alerts with enough context to find where things broke. The WooCommerce webhook is checked independently every hour, so a broken connection between the store and the automation gets caught even when no refund is currently in flight. Every Monday, an automated report collects all unresolved cases — pending, in manual review, or errored — and sends a summary by email and Telegram.

System architecture

The system connects WooCommerce, Mollie and e-Boekhouden through n8n and coordinates 11 workflows covering refund processing, chargebacks, retries, audits, monitoring and reporting.

Core components:

• n8n for orchestration across all 11 workflows
• WooCommerce API for orders and refund events
• Mollie API for payment and refund status
• e-Boekhouden API for invoices, credit notes and mutations
• Telegram and email for alerts and weekly reports
• a five-state case model: In Progress, Waiting, Manual Review, Error, Completed

Every refund keeps its full operational history — statuses, external IDs, API responses, accounting mutation IDs, retry attempts, and final outcome — which makes every automated decision traceable.

Results

Standard refunds move through the system without anyone touching them.

Outcomes:

• 100% of standard refunds processed automatically, end to end
• zero duplicate accounting entries, because every mutation is checked before it’s created
• pending cases retry themselves; only genuinely ambiguous partial refunds reach a human
• an independent audit every 3 hours, separate from the main process, catches silent failures
• a complete audit trail for every refund: every check, every API response, every decision

It’s a reconciliation system built around the full lifecycle of a refund — standard cases close themselves, and human attention goes only to the cases that actually need judgment.