When a sync fails.
Every connection fails sometimes: a bank renews its consent, a platform has a bad night, someone resets a password. What matters is that a person knows the same morning, nothing is done twice, and the fix has a name and a date next to it. This is how we build for that. The example beside it is fictional.
- The check failsOne client file's bank feed returns an error06:00
- RetriedTwice, ten minutes apart, then it stops and tells a person06:20
- Alert to usWe look: the bank's consent has lapsed, so it needs the firm06:25
- Owner and deadlineA task for the file's bookkeeper, due before 10:0006:30
- Fixed and checkedRe-authorized, missing days pulled, the next run is clean09:10
What failed means
Three ways a sync fails.
Only one of them makes a noise on its own. The other two are why we build checks, not just alerts.
A run that errors
The flow starts and something stops it: an expired login, a platform that is down, a record it does not recognize. This is the easy one, because the automation platform records the error.
A run that never starts
The schedule is switched off, a plan limit is reached, or a trigger stops firing. Nothing errors, because nothing ran. So every flow we build reports in when it finishes, and a missing report is an alert of its own.
A feed that silently stops
The connection says it is fine, but no new data arrives. Bank feeds do this when a bank's consent lapses, and it can go unnoticed for weeks. So we check what arrived, not only whether the connection is up.
How it is noticed
Checked on a schedule. Us first, then you.
Three layers, so a person sees a failure the same morning.
Checks on a schedule
Before your team starts the day, each flow is checked: did it run, did it finish, and did the data it should bring actually arrive. For bank feeds, that means the date of the last line on every account.
Alerts to us first, then your firm
On stewardship, alerts come to us first. We work out whether the fault is in the flow or outside it. If it is ours, we fix it. If it needs someone at your firm, such as re-authorizing a bank, it goes to that person with what to do.
A board your team can see
Each flow's last good run, with the time, in one place. A flow that failed shows its last good data and says how old it is, so nobody works from stale numbers without knowing.
Retries
What a retry does, and what it never does.
Most failures clear on their own within minutes. Every step that writes is built to check before it writes, so running it twice is safe. That is a rule of how we build, not a hope.
A retry does
- Runs the failed step again a few times, spaced out, before anyone is alerted
- Checks first whether the work was already done, and skips it if so
- Picks up from the last good record, so a gap is filled rather than skipped
- Logs each attempt, so the monthly summary can say what happened
A retry never
- Posts a transaction, sends an invoice or creates a record twice: each write carries a reference we set, and the step looks for that reference before it writes, so a repeat finds the record and stops
- Posts or pays on its own: anything that moves money is drafted, and a person at your firm approves it
- Keeps trying in silence: after the last attempt, a person is told
- Changes a rule or a mapping to make an error go away
An owner
Every exception gets a name and a date.
An alert nobody owns is noise. So each one lands as a task in the practice manager your team already uses.
- 01
It becomes a task
In Karbon, TaxDome or whichever practice manager you run, on the client it belongs to, with what failed and what to check first.
- 02
It gets an owner
Set by rules agreed with you before anything is built: a stopped bank feed goes to the bookkeeper who owns that file, a payroll mapping to whoever runs payroll, a fault in the flow to us.
- 03
It gets a deadline
Also agreed up front, by how much it holds up: a stopped feed before the end of the morning, a held payroll journal before the next pay run.
- 04
Late goes up a level
If the task is still open at its deadline, the person you named, usually the owner or a reviewer, is told. Nothing waits quietly.
- 05
Closed by the next good run
The task closes when the next run confirms the data is flowing again, not when someone ticks it off.
Afterwards
One page, once a month.
You should not have to ask what went wrong last month.
The monthly summary
On stewardship, every month: what ran, what failed, how long each failure took to fix and who fixed it, and what we changed. See a sample monthly summary.
The runbook
Each flow comes with a runbook your team keeps: the checks, who owns what, how to re-run it and how to pause it. If you run it yourselves, alerts go to the people it names. See a sample runbook.
Let’s look at the hand-offs
Tell us where the work slows down.
Book a 20-minute call and tell us which tools your firm uses and where the work gets stuck. We will say whether an assessment makes sense.
or email connect@cudalo.com
- The systems your firm uses
- The process you want to improve
- What your team does manually today
For accounting & bookkeeping firms
in the US, Canada & UK.