How to Automate Reconciliation Checks Between Systems
Two systems that are supposed to agree, and a person whose job is to prove they do. That is reconciliation. The payment processor reports one payout total, the accounting ledger reports another, and someone opens two tabs, exports two files, and spends an hour finding the refund that posted a day late. When you automate reconciliation, you are not removing the judgment. You are removing the fetching, the reformatting, and the line-by-line eyeballing, so a human opens a short list of real differences instead of a spreadsheet where nearly every row already matches.
This guide builds a working cross-system reconciliation check in Skopx: what it compares, how often it runs, what it does when the numbers disagree, and the exact sentence you type to create it.
What manual reconciliation actually costs teams
The cost is rarely a line item, which is why it survives for years. It shows up in five places.
Cadence collapse. Reconciliation that requires an hour of human effort gets done monthly, because nobody has an hour every morning. A break that happened on the 3rd is discovered on the 31st, after the customer has already been invoiced twice.
Detection lag. The gap between when a difference appears and when someone notices it is the whole risk. Duplicate charges, failed webhooks, a sync that quietly stopped writing to the ledger: all of these are cheap to fix on day one and expensive to unwind at quarter close.
Key-person risk. The person who knows which columns to compare, which timezone the export uses, and which three counterparties always settle late is usually one person. When they are on leave, the check does not happen.
No audit trail. A reconciliation done in a local spreadsheet leaves no record of what was compared, when, or what the differences were. Auditors ask, and the answer is a screenshot.
Sampling. Under time pressure, people check the biggest twenty rows and call it done. The break hiding in a hundred small transactions is the one that becomes a restatement.
Why finance teams automate reconciliation checks
Machines are excellent at set differences and terrible at judgment. Reconciliation splits cleanly along that line: pulling both sides, normalizing formats, and finding what does not match is mechanical. Deciding whether a variance is a timing difference, a fraud signal, or a bad integration is human work.
The real prize is frequency. Once the mechanical part costs nothing to repeat, a monthly reconciliation becomes a daily one, and detection lag drops from weeks to hours.
Most finance teams have several of these pairs running at once:
| Reconciliation pair | Match key | Most common break |
|---|---|---|
| Payment processor to accounting ledger | Payout ID, settlement date | Refunds and fees posted to the wrong period |
| Bank statement to ledger cash account | Amount plus date window | Transactions in transit at the cutoff |
| CRM closed-won to invoices raised | Deal ID or customer ID | Deal marked closed, invoice never created |
| Subscription billing to revenue schedule | Subscription ID | Mid-cycle upgrades and prorations |
| Inventory system to purchase orders | SKU plus PO number | Partial receipts recorded as full |
| Payroll provider to expense ledger | Pay run ID | Reimbursements double-booked with expense claims |
Each is the same workflow shape with different connectors, so building one well means you can build the rest in an afternoon. Skopx connects to nearly 1,000 integrations, so both sides are usually available.
The workflow design
Every reconciliation check has the same five moves: pull side A, pull side B, put both into a comparable shape, compare, and report what did not match. That is it.
Daily two-system reconciliation
Every weekday 07:00
Fetch processor payouts
Fetch ledger entries
Normalize both sides
Compare and explain
Post break list
Three design decisions matter more than the connectors you pick.
Pick a window, not "everything". Compare a bounded period, for example the previous business day or a rolling seven days. Unbounded pulls get slow, hit API limits, and re-surface breaks you already investigated.
Define tolerance up front. Currency rounding and fee timing produce differences that are noise. Decide the threshold, for example anything under one unit of currency or under a small percentage of the batch, and make the workflow classify below-tolerance items separately instead of alerting on them.
Report differences only. A message that says "412 transactions matched" trains people to ignore it. A message that says "3 items need review, oldest is 2 days old" gets opened.
What to automate versus what stays human
Skopx has no human-approval step, and reconciliation is one of the processes where that constraint pushes you toward the right design anyway. The workflow gathers evidence and prepares the decision. A named person makes it.
| Step | Automated | Human |
|---|---|---|
| Pulling both sides of the data | Yes | |
| Normalizing dates, currency, and IDs | Yes | |
| Matching and flagging differences | Yes | |
| Classifying likely cause and drafting a summary | Yes, drafted | Reviewed |
| Logging the run and the break list | Yes | |
| Posting an adjusting journal entry | Human | |
| Issuing a refund or reversing a charge | Human | |
| Writing off an aged difference | Human | |
| Contacting a customer about a discrepancy | Draft prepared | Human sends |
The pattern to internalize: the workflow can create a ticket, write a summary, attach the two conflicting records, and tag the controller. It should not touch the ledger. Anything that moves money, changes a book, or reaches a customer gets prepared and routed, never executed. The same principle applies when you automate invoice processing and when you automate expense review and approval routing: capture and prepare are safe to automate, commit is not.
How to automate reconciliation in Skopx, step by step
There is no drag-and-drop canvas. You describe the workflow in plain English on the workflows page and Skopx assembles the steps, which you then open and adjust.
1. Connect both systems first. Reconciliation needs read access to two sides. Connect your payment processor and your accounting system, or your bank feed and your ledger, before you describe anything. A workflow that references a disconnected tool fails on its first run with an authorization error.
2. Type the sentence. Be specific about window, cadence, timezone, and destination:
Every weekday at 7:00 AM Europe/London, fetch yesterday's payouts and refunds from Stripe and yesterday's entries in the bank clearing account from Xero. Normalize the dates and amounts, compare the two sets by transaction reference and amount, and use an AI step to list every item that appears in one system but not the other or where the amounts differ by more than 1.00. Post the list to the #finance-ops Slack channel with a one line summary, and say "all matched" if there are no differences.
3. Check the trigger. Open the generated workflow and confirm the schedule and the IANA timezone. Schedules run at a 15 minute minimum, hourly, daily, or weekly. Reconciliation almost always wants daily on a weekday morning, after the overnight settlement files have landed. Running at 00:05 is a classic mistake: the data you want is not there yet.
4. Verify the fetch steps. Each integration action should be scoped to the window, not to "all". Confirm the date filters use the trigger time, for example {{ trigger.timestamp }}, rather than a hardcoded date that was true the day you built it.
5. Wire the transform. A field transform step is where you strip currency symbols, force both sides to the same decimal precision, and cast dates to a single format. Skipping this is the single biggest cause of false breaks. Two systems that both say "the 3rd" in different timezones will not match as strings.
6. Feed both outputs into the AI step. The comparison step needs both sides in its prompt, referenced as {{ steps.fetch_payouts.output.items }} and {{ steps.fetch_ledger.output.items }}. Ask it for a structured result: matched count, unmatched from side A, unmatched from side B, amount differences, and a one sentence likely cause for each. AI steps run on your own provider key with zero markup, so you need a key connected in settings before this step will execute.
7. Send the report. The final integration action posts to Slack, email, or a ticket system, using {{ steps.compare.output.summary }}. Keep the message short and link out to the full run.
8. Run it manually. Every workflow can be triggered by hand. Run it, open the run history, and read each step's real output before you let the schedule take over.
Add severity routing to the check
Once the basic version is trustworthy, add an if/else condition so that small differences are logged quietly and material ones interrupt someone.
Reconciliation with severity routing
Daily 07:00
Fetch both sides
Match and score
Over tolerance?
Log to sheet
Create finance ticket
Alert controller
The condition uses operators like equals, contains, greater_than, and is_empty against a field from the previous step, for example {{ steps.compare.output.max_variance }} greater_than 100. The clean path still writes a row to a sheet, which gives you a dated record that the check ran and found nothing, which is exactly what an auditor wants to see.
Workflows are acyclic and capped at 20 steps, so resist the urge to build one mega-workflow that reconciles six system pairs. Build six small ones. They are easier to debug, and a failure in the payroll check does not block the bank check.
How to tell it is working
Every run is inspectable. Open the run and you see each step's real output, how long it took, and the exact error text if it failed. Use that rather than trusting the Slack message.
Watch four things in the first month:
Parallel run. For two weeks, let the workflow run and keep doing the manual check. Compare the break lists. If the workflow finds everything the human finds, retire the manual pass. If it finds extra items, your tolerance or normalization needs tuning.
False break rate. Count how many flagged items turn out to be timing noise. If more than a small fraction are noise, the fix is almost always in the transform step, not the AI prompt.
Time to close a break. The number that proves value is how long a real difference stays open. It should fall sharply once detection moves from monthly to daily.
Silence. If nobody has commented on the daily message in three weeks, either you are reporting matches instead of differences, or the wrong channel is receiving it.
Common mistakes
Comparing before normalizing. Timezones, decimal precision, and currency symbols cause more false breaks than every other cause combined. Transform first, always.
No tolerance threshold. Without one, rounding noise floods the report and people stop reading it within a week.
Alerting on success. Report exceptions. A daily "all matched" one-liner is fine, a daily list of 400 matched rows is not.
Expecting the workflow to fix the break. It should not post the journal entry, issue the refund, or email the customer. It prepares and routes. A person commits.
Assuming a missed schedule will fire late. If a scheduled run is missed beyond the 2 hour grace window, it is recorded as failed rather than fired late. For a 7:00 AM daily check that means you will see a failed run in history, not a surprise 3:00 PM comparison against stale data. Check run history weekly.
Expecting loops. Workflows are acyclic. If you need to process 500 rows, have the integration action return the batch and let a single AI step reason over the whole set, rather than trying to iterate.
Building it once and never revisiting. When someone adds a new payment method or a new ledger account, the check silently stops covering it. Review the scope quarterly.
Frequently asked questions
Can Skopx post the adjusting journal entry once it finds a difference?
It can, technically, since your accounting tool is a connected integration with write actions. It should not, and this is a deliberate design position. Reconciliation differences frequently have causes the data does not reveal. Have the workflow create the ticket, attach both records, and tag the owner. The person with the context posts the entry.
What happens if the schedule is missed?
Missed schedules beyond a 2 hour grace window are recorded as failed rather than fired late. That is intentional for finance work: a reconciliation that runs against the wrong window is worse than one that did not run, because it produces confident wrong answers. The failed run is visible in history.
Do I need my own AI provider key?
Yes, for the comparison and summarization steps. AI steps bill to your own provider key with zero markup. Integration actions, conditions, and transforms do not need one, so a purely rule-based reconciliation that compares totals with a greater_than condition can run without any AI step at all.
How do I handle three-way reconciliation?
Add the third fetch as another integration action and reference all three outputs in the comparison step. You have up to 20 steps, which is comfortable for a three-way check. If the logic starts branching heavily, split it: one workflow reconciles A to B, a second reconciles the result to C, triggered by webhook from the first. Each webhook trigger has a unique URL and a per-workflow secret.
What does this cost to run?
Skopx is $5 per month for Solo, $16 per seat per month for Team, and $5,000 per month for Enterprise. Every plan bills from day one. AI steps bill separately to your own provider key at zero markup. If you are also automating the collections side, the same schedule-and-notify pattern covers payment reminders and dunning.
Start with your highest-volume system pair, build the basic version, run it manually until you trust it, then let the schedule take over. Build it on the workflows page.
Skopx Team
The Skopx engineering and product team