The Sync With No Name on It
The accounting sync keeps a proper log: what it moved, when it started, how long it took and what went wrong. There is a column for who started it, and a way to read that column, and nothing has ever written to it.
An integration between two finance systems is the kind of thing that runs quietly for months and then matters enormously for one afternoon. Something went across that should not have, or did not go across that should have, and somebody has to reconstruct what happened.
The log is what you have. So the question worth asking, long before that afternoon, is what the log records — and specifically whether it records a person.
What is in the log
More than many. Each run records what kind of sync it was, when it started and finished, how long it took, whether it succeeded, and the error text if it failed. The screen shows recent runs and a count of failures, so a persistent problem is visible rather than buried.
That is a real operational log. It answers "is this working", "when did it stop", and "how long has it been taking" — and those three questions cover most of what anybody asks most of the time.
There is a place in it for who started the run. It is never filled in.
Not an oversight in the design — the design is complete. There is even a defined way to look the person up. The step that records them was left out of every path that writes a row.
Why "who" is the question you eventually want
Because a sync can begin in two very different ways, and the difference is the first thing you need to establish.
A scheduled run is the system doing what it always does. If one of those went wrong, the cause is in the data or the connection, and you look at the error and the timing.
A manual run is a person deciding to push something across, usually because something else was already not right. That person had a reason, they were looking at something, and they know a piece of context that is nowhere in the log. Finding them is often the fastest route to understanding what happened, and it is frequently the only one.
A log that cannot separate those two makes every run look like weather.
What the log answers well
- Did it run, and when
- Did it succeed or fail
- How long it took, and whether that is getting worse
- What the error said
- How many failures there have been recently
What it cannot answer
- Was this the schedule or a person
- Which person, if it was one
- Why they ran it then
- Whether two runs close together were one person retrying
- Who to ask about this particular afternoon
The wider pattern, which is worth recognising
Operational logs and audit logs get built by different people at different times for different reasons, and they answer different questions. An operational log exists so engineers can see whether a thing is healthy. An audit log exists so a business can see who did what.
Integration runs sit precisely between the two, and consequently often fall into the space between them. They look like machinery, so they get an operational log. They are frequently started by people, so they need an actor. The column usually exists, because whoever designed the storage knew that — and it usually does not get filled, because whoever wrote the code that starts the run was thinking about the schedule.
What to do while it is true
Three habits that cost nothing
- Agree that manual syncs are announced. One line in a team channel — "pushing purchase orders across, chasing a missing bill" — and the context that the log cannot hold has somewhere to live.
- Note the time when you run one by hand. A run at an unusual hour is the strongest available signal that a person was involved, and a note turns a guess into a fact.
- When something looks wrong, check the timing pattern before the error text. Runs that cluster irregularly are people; runs at the same time each day are the schedule. It is a rough test and it is the one you have.
Three questions for any integration you depend on
Does the sync history show who started each run?
What you will hear
Usually a yes, then a check.
How to read it
Ask them to point at it on a real row. A column existing in an export is not the same as a value being in it, and this is the exact failure described on this page.
Can I tell a scheduled run from a manual one?
What you will hear
Sometimes, by the timing.
How to read it
By the timing is a workaround, not a record. If that is the answer, the log is telling you about machinery and you will be reconstructing the human half from memory.
How long is the sync history kept?
What you will hear
Varies.
How to read it
Worth asking in the same breath. The afternoon you need the log is often months after the run, and a history trimmed to thirty days is a different product from one that keeps a year.
What AWRA OpsHub does today
- A run recorded for every sync — its type, start, finish, duration and outcome — visible on the accounting screen and through the interface.
- The error text kept on a failed run, so a recurring problem can be diagnosed rather than only counted.
- A failure count, so a sync that has been quietly failing announces itself rather than waiting to be noticed.
- A daily digest of integration failures, so a broken connection reports itself to somebody rather than only sitting in a list.
More we can add to your workspace
- The person who started a run recorded against it, so a manual push and a scheduled one are distinguishable in the history.
- A marker separating scheduled runs from manual ones, which is the cheaper half of the same question.
- A note or reason on a manual run, so the context that prompted somebody to push is kept with the run rather than in a chat message.
- Retention stated on the sync history, so you know how far back the record goes before you need it.
Where we point you to a specialist
- An operational log and an audit trail stay separate things and we would keep them that way. The sync history exists to answer whether the connection is healthy; making it the system of record for user actions would produce one log that answers both questions vaguely.
- What your accounting package does with what we send is governed by that package and your accountant. We record what we sent and when; reconciling the far side belongs with whoever owns the ledger.
- We would decline to infer an operator from timing. A run that happens to fall outside schedule hours is a guess, and a guess written into a log is worse than an empty column, because the next reader will believe it.
Operator attribution on a sync run, a scheduled-versus-manual marker and a reason on a manual push are scoped work we can quote on.
Two, and the first is genuinely small
The column exists, the way to read it exists, and the runs already record everything else. What is left is filling it in at the point a person presses the button.
The operator on the run
Recorded where a person started it, empty where the schedule did — which by itself separates the two kinds of run without needing a second field.
A reason on a manual push
One optional line at the moment somebody runs a sync by hand. It is the piece of context that never survives otherwise, and it is worth more six months later than the duration figure beside it.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your finance team pushes syncs by hand when something looks wrong, the first item is the one to raise.
Talk to us about accounting integrationThe short version
An integration log that records what and when and not who is a machine's diary, and it is exactly half of what you want on the afternoon something has gone across wrongly. The half it is missing is usually a single field that already exists in the storage, because the person who designed it knew — and the person who wrote the code that starts a run was thinking about the schedule. Go and look at one row of your own sync history and see whether a name is on it.
Open one row of your sync history
Not the summary — one run. See what it tells you, and imagine reconstructing a bad afternoon from it six months from now. That gap is the one worth closing before you need it.
Talk to us about integrations