Scheduled Xero Reports: Your Cheetah Reports Now Run Themselves

For a while, Cheetah had a quietly embarrassing gap. We'd spend weeks encoding a client's reporting logic — the account mappings, the eliminations, the KPIs, the exact layout their board expects — until the whole thing ran off one button. Then, every month, a human still had to remember to press the button.

That's not automation. That's a very sophisticated doorbell.

So we closed the gap. Cheetah reports can now run on a schedule: every Monday at 9am, the 3rd of every month, daily at 7 — whatever cadence the report deserves. The report generates itself, and everyone on the recipient list gets an email with a link to the finished Google Sheet and a one-click Excel download. Nobody logs in. Nobody remembers anything.

Here's what shipped, and the one design problem that made scheduled Xero reports more interesting to build than they sound.

Xero won't do this for you

First, the obvious question: why isn't this just a Xero feature?

Xero lets you build custom report layouts and save them. What it won't do is run one on a schedule and email it to anyone. There's no "send this P&L to the directors on the 3rd of every month" anywhere in the product. The closest you get is a human opening the report, exporting it, and attaching it to an email — which means the delivery of your reporting is only as reliable as that human's calendar.

Some of the reporting add-ons handle scheduling, but on their terms: their dashboard, their template, their idea of what your P&L should look like. (We've written a full comparison of the add-on landscape if you want the long version.) If the report you actually need is bespoke — and if you're a Cheetah client, it is — scheduling was still your job.

The problem: a schedule can't store dates

Here's the bit that made this a real feature rather than a cron job bolted onto a button.

When you run a report by hand, you pick the dates: 1 July to 31 July. But a schedule can't store dates — a schedule that says "1 July to 31 July" is correct exactly once and silently wrong forever after. What a schedule has to store is a rule: "last month," whatever last month happens to be when the run fires.

So every date input a Cheetah report takes now has a vocabulary of rolling rules behind it. At run time, the rule resolves into the exact same inputs you'd have picked by hand, and the report runs through the exact same generator the button uses. Same logic, same output, same formatting — the report doesn't know it was scheduled. That mattered to us: the moment a scheduled run takes a different code path from a manual one, you have two reports that slowly stop agreeing with each other.

Two smaller details we sweated:

Partial periods are labelled as partial. Rules like "this month" or "year to date through today" include the in-progress period, which means the figures move between runs. That's sometimes exactly what you want — but you should never discover it by accident, so those rules are explicitly marked and the email subject carries the period the report actually covers.

Periods roll at your midnight, not a server's. "Yesterday" flips at Singapore midnight, where most of our clients close their books — not at UTC midnight, which is how a daily report quietly ends up covering the wrong day for eight hours.

When a run fails, that's our problem

The nightmare scenario for any scheduled report is silent failure: the email doesn't arrive, nobody notices for three weeks, and the directors have been making decisions off a stale pack.

We built the failure path first. If a scheduled run errors — Xero hiccups, a token expires, anything — we get notified immediately, with the full error, and we fix it and re-run. You don't get a broken link, and you don't get the job of chasing us. Every run is also logged, so there's an audit trail of what ran, when, for which period, and what it produced.

And if our infrastructure misses a window entirely, the schedule catches up with exactly one run covering the latest missed slot — not a backlog of five identical emails arriving at once on Tuesday.

What people are actually scheduling

The early patterns are the ones you'd guess, which is reassuring:

• The monthly management pack, on the 3rd of the month, covering last month. This is the big one — the management accounts problem was already about encoding the logic once instead of rebuilding it monthly; scheduling removes the last manual step.
• Weekly sales and cash reports, Monday morning, covering the last completed week. In inboxes before the ops meeting starts.

The common thread: these were all reports someone was already generating on a rhythm. The rhythm was just living in a person's head when it doesn't need to be.

The button is still there

Scheduling doesn't replace on-demand runs — you can still generate any report manually, for any period, whenever someone asks an unexpected question. The schedule just handles the runs that were never a decision in the first place.

If you've got a Cheetah report you're running on autopilot every month anyway, tell us the cadence and we'll put it on a schedule. And if your month-end still involves rebuilding reports by hand before anyone can even think about scheduling them, Cheetah starts a step earlier than that.