Monthly Check: Did the Automation Run

The monthly check that your automation ran

By the end of this check you will know, for every background job your business leans on, whether its clock fired this month and whether the job did its work — and you will hold a dated record of the part the product keeps for nobody. It is for whoever administers the tenant or signs off month-end, and takes about twenty minutes on the first working day of the month once the Step 1 list exists.

The check at a glance

Decide which clocks you rely on, and who owns each one’s result.
Read every ACTIVE row’s Last Run Date against its timetable: fired, not worked.
Look for each job’s own evidence, on the screen that job writes to.
Check the five default clocks that fire and do nothing as installed.
When a clock fired and the work is missing, send the four things support needs.
Write the result down, and hand over what the product leaves to you.

Meet GadgetSphere

GadgetSphere’s tenant was created in mid-2025, before several of today’s default clocks joined the set. Its three companies file e-invoices through the default passes, its 28 cashbooks rely on the bank-reconciliation refresh, the Historical Debtor Report is read on the 2nd, and the online arm’s web chat creates contact-centre tasks.

Two words that decide the whole check

Fired is not worked. A clock fires when the platform puts its job on the queue (or finds the same job already waiting) and stamps Last Run Date. Most defaults run the job in that same pass, the rest a little later; either way the date is stamped whether the job then succeeds or fails, and a failure is recorded where the Scheduler never shows it. So the date answers “did the clock fire”, and only the job’s own output answers “did it work” (Scheduler › Lifecycle and effects).

Installed is not working. BigLedger installs its default clocks switched on, each with empty settings. Fourteen of the twenty supply their own defaults and work as installed. Six do not: five fire on time and do nothing — two of them harmlessly, because the platform’s own round does that work anyway — and one does half its job (Step 4).

Before you start

The Scheduler screen has been broken since 19 October 2026, wherever it is opened (a known defect): the listing shows one ERR row; clocks keep firing. Until the fix ships, do Step 2 by asking BigLedger support for each row’s Status, Last Run Date and Json, or through the API if you already integrate (Run something on a schedule).
Hold API_TNT_DM_SCH_CRONTAB_READ, or ask the administrator who does.
Have last month’s Step 1 list (the first month, you make it).

Step 1: Decide which clocks you rely on, and who owns each result

The product does not decide this for you. The decision belongs to whoever owns month-end, usually the finance lead, made with BigLedger at go-live and again whenever a release note names a new job (Deciding which jobs run on your tenant).

Write the list as three columns: the job’s code, the timetable you expect, and the person who reads its output — at GadgetSphere, the e-invoice administrator, the accountant who runs the aging report, whoever reconciles the banks, the stock controller and the contact-centre supervisor. A clock nobody reads the output of is a clock nobody will notice has stopped.

Common failure: the list is the default set, copied. A tenant created before a default joined the set does not have it, and a job your business needs may not be a default at all — the Blacklist Overdue Customer sweep behind credit control ships with no clock (which defaults your tenant has).

Step 2: Read Last Run Date against the timetable

For every ACTIVE row on your list, compare Last Run Date with its expression. As installed, the e-invoice passes run every ten to thirty minutes, the stock, cashbook and task clocks every fifteen, the received-e-invoice staging run every minute, the task expiry sweep daily, and the deposit month-closing, the aging snapshot and the classification refresh on the 1st.

A date that fits the expression means the clock fired. Go to Step 3. (On a row created since last month the date is its creation moment until it first fires: compare it with the Created Date.)
A date older than its expression allows means the clock did not fire: one ACTIVE row with an expression the clock cannot read stops every clock on the tenant, and an unregistered code is dropped without a word (Scheduler › Troubleshooting).
An Updated Date later than last month’s check means somebody saved the row. Ask who, and why, before you trust it.

Common failure: reading a current date as proof the job worked. It proves the clock fired. The job may have failed in the same pass, and the failure is written to a table the Scheduler never shows.

Step 3: Look for each job’s own evidence

One row per job you rely on; each links the page that owns the proof.

Job	Where the work shows	What an empty result means
The e-invoice passes (submission, status, consolidation, batch cycle, token)	My E-Invoice Admin’s queues — the five-minute check	Nothing waiting beyond its age. An ageing queue row carries its own error; a held document waits for a run or a person by design
Validated-PDF e-mail	My E-Invoice Admin’s Email Printable Queue and its history (the validated PDF e-mail)	Rows that stay queued are that page’s troubleshooting, not the clock’s
Monthly aging snapshot	Historical Debtor Report and Creditor Report show last month-end	No month-end row for a customer who had a balance: the clock did not fire, or the job failed — read the date. Do not press Run Now to fill it: a late run stores today’s balances as last month-end, for good (why)
Bank-reconciliation refresh	A reconciliation’s cashbook closing follows a back-dated payment in its period within about half an hour (the stored balances)	The closing stays as it was at Create: no clock, the clock is off, or the refresh failed
Cashbook watchdog	A cash transfer or settled document whose cashbook lines were missing now has them (Cashbook › Lifecycle)	Nothing to repair leaves no mark; check only when Trace Document showed a missing cashbook line last month
Classification-code refresh	A description that changed in Doc Item Maintenance › Classifications, and only when LHDN reworded a code	No change is normal. A code LHDN added and you do not see is Step 4
Received e-invoices staging	My E-Invoice Admin › External Reception → Queue	Empty on a production company whose suppliers e-invoice you: check Step 4 before concluding nobody sent anything
Contact-centre task poll	Bot hand-over tasks leave `CREATED` within a round or two of the platform clock (How a task is routed)	A task still `CREATED` after an hour is a routing problem on that page, never the Scheduler row
Stock-balance repair queue	Balances the inventory watchdog found wrong are re-summed (Stock Balance › Background jobs)	A balance the watchdog flagged that stays wrong is Step 4
Deposit month-closing, temporary-document clean-up, task expiry	Nothing a reader can see — the deposit job’s two lines belong to no deposit and no register screen shows them (Deposit › Rollover)	Skip

Step 4: Check the five defaults that fire and do nothing as installed

Every default clock is inserted with empty settings. Fourteen jobs carry their own defaults and run. Five fire on time and do nothing: Last Run Date moves, the work does not happen. Two of those five are harmless, because the platform’s own round runs the same job with the right settings on every pass. A sixth runs and does half its job. The settings the others need are BigLedger’s own values (a callback address, the tenant it calls back as, a batch size), so ask BigLedger support to set them; do not save a Json yourself if it holds a credential (the caution).

The codes to look for in the listing are in The clocks BigLedger installs.

Default clock	As installed	What you see	Ask BigLedger to
The stock-balance repair drain (the stock schedule)	No `limit`, so the drain selects zero rows. The repair requests the inventory watchdog files sit in the queue	A balance the watchdog flagged stays wrong; the Data Fix rebuild still works, because it runs in the request	Set the row’s properties: a positive `limit`, and the callback address and tenant code the drain calls with
The contact-centre task poll and the task expiry sweep (two of the three housekeeping schedules)	No request URL, and every read of the task queue sits behind one — but the platform’s own round runs both jobs with the settings on every pass	Nothing: tasks are routed and expired by the round whatever these rows say	Nothing; leave them
The e-invoice auto-cancel job	Per-document settings no clock can give; every firing adds an empty event that fails with an error row and cancels nothing. Cancellations raised by another system arrive through an integration route, not this clock	An error row every five minutes while the row is ACTIVE	Nothing to set; switch the row INACTIVE if the error rows bother you
The received-e-invoice staging run (the e-invoice schedule that fetches from LHDN every minute)	No `lhdnEnvType`, so it reads the sandbox intermediary configuration; a production company is never polled	External Reception → Queue stays empty on a live company	Set `lhdnEnvType` to `PRODUCTION` on the row
The classification-code refresh (the e-invoice schedule on the 1st)	Runs, updates the descriptions of codes you hold, and never adds a code LHDN publishes; a failed download still ends as a success	A new LHDN code is not in the picker	Nothing on the clock; add the code by hand after an LHDN notice

Common failure: adding a second row for the same job “to make it work”. It fires beside the first and, with the same empty settings, does the same nothing; the fix is the settings, not another row.

Step 5: When a clock fired and the work is missing

A job that starts and fails writes its error to a table the applets do not show — or, for several e-invoice jobs, only to the server log — and nothing in the clock or the queue alerts anyone; the one e-mail that exists, the e-invoice failure report, is itself a clock somebody has to add (Pools and queues). So when Step 3 finds a current Last Run Date and no evidence, send four things (what to send):

the job’s code, exactly as written on the row;
your tenant code — not the company code, not the branch code;
the Last Run Date as shown, with your time zone (the listing shows browser time);
what you expected to see, from the Step 3 table, and that it is not there.

Before you send it, read the row’s Json: {} on a Step 4 row is the answer already. The queue itself is not something you can open, and Last Run Date moves even while an identical job is still waiting (Lifecycle), so report what you saw and let support find the backlog or the failure.

Step 6: Write it down, and hand over what the product leaves to you

Four things the product leaves to a person. Name them once, on the Step 1 list.

The product does not	Who does it instead	When	They know it is right when
Watch its own clocks	The tenant administrator	First working day of the month	Every ACTIVE row’s Last Run Date fits its expression (Step 2)
Tell anyone a job failed	The owner of each job’s output, from the Step 1 list	The same morning, and whenever that output is read	The Step 3 evidence is there where there was work to do, and each Step 4 row is set or recorded as left
Keep a record that the check was made	The administrator, in a dated note kept with the month-end file	Each month, before the file is closed	The auditor or the next administrator can read who checked what, and when
Decide which jobs should run	The finance lead, with BigLedger	At go-live and at every release note naming a job	Every job on the Step 1 list has a row on your tenant and a reader, and the list was re-read at the last release note

What success looks like

Thirty seconds: open last month’s note. It names every clock you rely on with a Last Run Date that fits its expression, the evidence seen for each job, which Step 4 rows are set and which were deliberately left, and it is dated and signed. No note, no check — whatever the listing says.

Common mistakes

What goes wrong	Why	Fix
A current Last Run Date is read as “the job worked”	The date is stamped whether the job then works or fails	Step 3: the job’s own output
An ACTIVE default row is read as “this runs”	Five defaults read a setting the install never writes	Step 4: read the row’s Json; ask BigLedger to set it
Run Now pressed on the aging snapshot to fill a missed 1st	A late run stores today’s balances as last month-end, for good	Leave it; tell whoever reads the report (why)
Every clock stopped at once and nobody noticed for a month	One ACTIVE row the clock cannot read stops every clock, and nothing on a screen says so	Step 2 on every row, every month; the fix is in Scheduler › Troubleshooting
The check is done, and not written down	The product keeps no record of it; for the auditor it did not happen	Step 6: the dated note in the month-end file