Job sheets-scheduled-export-stale-or-truncated · revised 11 October 2026
Make a scheduled finance export to Google Sheets complete, current and honest on failure
One scheduled export to one Google Sheet shows every source row, a data-as-of time and a matching count; a failed run, including a silently short read, leaves the last good report with a warning.
You might be seeing
- The sheet always ends at the same row count, for example the first page of results
- Totals are old and nothing says when the data was last refreshed
- After a failed run part of the sheet is empty or mixed between old and new rows
No passwords, keys, card details or admin invites needed to start.
What usually happened
The scheduled script reads only part of the source data, writes straight into the live range, and has no completeness check or visible state. Paging is skipped, a run that exceeds a time or quota limit stops midway, or two runs overlap, so readers trust a report that is truncated, stale or half-written.
Who it’s for: A finance manager, bookkeeper or owner who relies on a Google Sheet that is refreshed on a schedule from the accounting system and has found it stale, cut off after the first page of rows, or half-written.
Usually starts when: A weekly report stops at a round number of rows, shows last month's figures, or has a blank section after a run that nobody noticed had failed.
The result: One named export writes every source row into a staging range, swaps it into the report only when the row count equals the source count, stamps a data-as-of time and a run status on the sheet, and on a forced failure, including a deliberately truncated read that the platform itself would call a successful run, leaves the previous complete report with a visible warning.
Check whether this job fits
Answer these from what you can see without sending logins, invoices or customer data. Nothing is submitted unless you choose to contact us; this is a fit check, not permission for us to touch your systems.
Checks you can run yourself
Compare source and sheet counts
Run the source report for one date range in the accounting system and count its rows. Count the rows in the sheet for the same range.
Look for: A sheet count that is lower and round (for example the source's first page) suggests truncation; a matching count with an old date suggests a stale schedule.
What you get
- The script and its schedule settings, with a note on the limits it works within
- A test log: a multi-page synthetic source, a run that reaches its deadline, an overlapping run and the sheet status after each
- A one-page runbook for a failed run: where to look and who restarts it
Included
- One scheduled export from one accounting report or list into one Google Sheet, built with a script bound to the sheet
- Reading every page of the source with the page size and incremental option the source documents, and counting rows read against the source's own total
- Writing to a staging range and swapping it into the report only after the completeness check passes
- A status block on the sheet: data-as-of time, row counts, last run result and the reason of any failure, plus a stale flag that a sheet formula computes from the data-as-of time so a stopped schedule shows even when no script runs
- A lock against overlapping runs, a self-imposed deadline below the platform run-time limit so the script stops cleanly and records why, and a stay-within-limits rule for the script's run time and call count
Not included
- Redesigning the report, adding charts or changing what the report measures
- Several exports, several sheets or a data warehouse; this scope is one export to one sheet
- Changing accounting data or approving what the figures mean
- Sharing or permission changes on the sheet, which stay with its owner
- Bookkeeping, tax, audit or any accounting advice, including deciding how a transaction should be treated in your accounts
- Changing posted, reconciled or locked-period transactions: your accountant or account holder decides and performs those
- Live changes: your authorised account holder applies any agreed change and holds the production keys
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Against a synthetic source of 250 rows, which exceeds the source's default page size, the report shows 250 rows and the status block shows 250 read of 250 total.
Evidence: The source count, the sheet row count and the status block.
With the read deliberately cut short after the first page (for example 100 of the 250 source rows), the run is treated as failed: the swap is refused, the report still shows the previous complete data, and the status block shows the shortfall, for example 100 read of 250 total.
Evidence: The source count, the rows read, the report before and after, and the status block.
With the script deadline set low enough to be reached partway through a run, the report still shows the previous complete data, and the status block shows the failure, the time and the reason.
Evidence: Before and after sheet contents and the status block.
Two runs started at the same moment do not interleave rows; the second waits or exits with a recorded reason.
Evidence: The execution log and the final row count.
The status block shows a data-as-of time within the agreed age after a successful run and its formula flags the report as stale when the age exceeds the agreed limit, including when no script has run since.
Evidence: The status block after a successful run and with the trigger deleted in the test copy for longer than the agreed age.
Sign-off. You inspect the named test evidence and sign off before payment. Your authorised account holder performs and verifies any live change, and decides what happens to records already posted.
If it fails. If an agreed check does not pass, you do not pay for this fixed scope. We hand over the findings and agree whether to stop or re-quote; no surprise work and no change to your live records.
When it fits, and when we stop
It fits when
- The export is a script bound to a Google Sheet, or can be rebuilt as one, reading from an accounting system or a synthetic source with paging
- The sheet owner can create the schedule under their own account and authorise the script
- A synthetic multi-page source exists or can be produced, for example a demo organisation with enough invented documents
- A person on your side names who receives a failure notice
- Real financial records, customer data and keys are handled only after written agreement, through a secure handoff we agree with you; the first enquiry and the fit check use invented or redacted examples
We stop and tell you if
- The export is built in a tool that cannot hold a script and cannot be rebuilt as one
- The source cannot be read page by page and has no total to compare
- The report must be real-time rather than scheduled, which needs a different design
What could go wrong
The previous script version and sheet are kept in the copy and in the sheet's version history. The sheet owner can restore them and delete the new trigger. No accounting data is changed by this job.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The completeness check compares against a count taken from the same truncated read, so it always passes. | The check uses the source's own total, and a test truncates the read on purpose to prove the swap is refused. |
| A trigger created by one person stops when their authorisation changes. | The runbook names the trigger owner and how to re-authorise; a formula-driven stale flag shows a stopped schedule even when no script runs. |
| The platform ends a run at its time limit before the script can record anything. | The script stops itself at a deadline below the limit and records why; a run the platform ends anyway leaves the previous report intact and shows as stale. |
| Overlapping runs interleave rows. | A lock serialises runs and an overlap test is a named acceptance check. |
An independent reviewer checks that the swap really cannot happen on a count mismatch, that a failed run leaves the old report intact, and that no real financial data is in the test copy or evidence.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the export, the sheet, the schedule, the acceptable data age and the failure recipient in writing
- Reproduce the truncation or stale data on a copy with a synthetic multi-page source and record row counts
- Read every page of the source using the source's documented paging, comparing with its reported total
- Write to a staging range, swap it into the report only after the count check passes, and write the status block
- Add the overlap lock and the limit-aware stopping rule, then force a timeout and an overlapping run
- Independent review of the script, the test log and the status behaviour, then hand over for the sheet owner to schedule under their own account
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If more reports depend on the same pattern, discuss applying it to further exports as separate fixed jobs.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Google documents the run-time and daily trigger limits for scripts; your own developer can check the script against them first. developers.google.com
- Google documents a lock service that keeps two runs from executing the same section at once. developers.google.com
Questions
Can it refresh in real time?
No. This is a scheduled export. Real-time needs a different design and quote.
Why a staging range?
Writing directly into the report means a failed run can leave it half-new and half-old. A staging range lets the swap happen only after the count matches.
What limits does the script have to respect?
Google publishes limits for script run time, daily trigger time and calls. The job works within them and reports a clear failure when a limit stops a run, rather than writing partial data.
Send an enquiry
Send us
- What the export reads, how often it runs and where it writes, in a few sentences
- The row count you expect and the row count the sheet actually shows, as numbers only
- Whether the script is bound to the sheet and who created its schedule
- Do not send credentials, bank details, invoices, customer records or confidential code in the first enquiry
Later, once you agree
- Editor access to a copy of the sheet and script containing no real financial data
- A demo organisation or synthetic source with more rows than one page returns
- The failure-notice recipient and the acceptable maximum age of the data, in writing
- A secure, company-controlled handoff route agreed in writing before any access; no passwords, keys or customer records by ordinary email
You keep the live accounting organisation, payment accounts, production keys and every customer and financial record. We work on an authorised demo, sandbox or synthetic copy through a company-controlled handoff, never a personal login. Your authorised account holder approves and performs any live change and checks the result under their own keys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “sheets-scheduled-export-stale-or-truncated” as the subject.