2 AM, and the CEO was still at the office. Smart Store (Korea's largest marketplace), Coupang, 11st, the own-brand site, Cafe24 MarketPlus. Five channels of settlement data lined up in Excel, cross-checking commissions row by row. Two nights each month closing the books, gone that way.
What the problem actually was
This shop (₩420M monthly revenue, mostly home & living) had a settlement process that looked simple from the outside: pull each channel's settlement statement, cross-check against sales records in the in-house ERP, hunt down the discrepancies. The problem was that all five channels delivered data in a different way.
- Smart Store — Excel download from Seller Center; order ID format 'N202607…'
- Coupang — settlement API available, but shipping fee and coupons live in separate fields
- 11st — CSV as email attachment; commission calculated differently per product category
- Own site — Cafe24 (Korean e-commerce platform) admin SQL report; VAT inclusive/exclusive mixed
- MarketPlus — PDF statement only, table structure shifts slightly each month
The person on point (the finance lead, who is also the CEO) had to reconcile these five sources into a single table. Commission rates vary by product category, then vary again by promotion enrollment. One row mispping and the whole check breaks.
That ₩2.2M is the decisive number. Undercounted commissions from the channel side, wrong entries on the ERP side, refunds double-processed. Miss those and it's straight loss. Catch them and someone has to work through the night, every night.
The key idea: from 'check everything' to 'check only exceptions'
The first principle we set when designing the n8n workflow: humans don't need to see the normal cases. Humans only look at what falls outside the rules.
How we built it
- Daily 3 AM schedule trigger pulls data from 5 channels (3 APIs, 1 email attachment parser, 1 PDF OCR)
- Normalize per-channel fields into a common schema — order ID, product SKU, list price, commission, shipping, VAT
- Query the in-house ERP (Postgres) for orders in the same period; match on order ID
- Cross-check against a per-channel commission-rate rules table — compute expected commission, compare to actual, take the delta
- Only rows with delta ≥ ₩500 or unmatched rows get flagged into a Google Sheet
- 8 AM daily Slack summary — X normal, Y need review, total delta ₩Z
How to handle a PDF statement
The nastiest piece was MarketPlus's PDF statement. The table structure shifted a bit each month, so regex parsing was out. We fed the PDF text into an AI Agent node and extracted via Structured Output.
// AI Agent node · PDF statement parsing
const schema = z.object({
settlement_period: z.string(),
items: z.array(z.object({
order_id: z.string(),
sku: z.string(),
gross_amount: z.number(),
commission: z.number(),
shipping_fee: z.number(),
net_settlement: z.number(),
})),
total_net: z.number(),
});
// Downstream validation node
const sum = $json.items.reduce((s, i) => s + i.net_settlement, 0);
if (Math.abs(sum - $json.total_net) > 10) {
throw new Error(`Sum mismatch: item sum ${sum} vs stated ${$json.total_net}`);
}Result
The number to pay attention to is the catch rate. When humans reviewed everything, we actually missed more. Catching a ₩500 gap at 2 AM with tired eyes is hard. The workflow does that without getting tired.
No more late-night settlement work. The workflow does it. I check one Slack report in the morning; only three or four flagged rows need a human. And we're catching receivables we didn't know about — so revenue actually went up.— Jaehyeon Lee · Store Owner
Time and cost to build
- Requirements gathering and per-channel commission rules documentation — 3 days
- n8n workflow development and per-channel parsers — 5 days
- AI parser prompt tuning and validation rules — 2 days
- 3 months of parallel operation (human reconciliation + automated) — learning edge cases
- Total build: 10 business days; parallel validation: 3 months
I want to stress the parallel-operation period. Never trust an automation workflow the day you ship it. Run it side-by-side with the human process for at least a month or two, and every time the two disagree, find out why. That period is what decides your automation's real accuracy.
Wrap-up
The core of this case isn't the tool. It's the perspective. Shift from 'check everything' to 'check only exceptions,' then codify the definition of an exception with clear rules and validation. That way humans focus on decisions that actually need judgment, and the repetitive work runs unattended.