Every finance and operations team has a version of this process. On the first or second Monday of the month, someone opens three or four different systems, pulls numbers out of each of them, pastes them into a spreadsheet, formats the table, writes an email, and sends it to a distribution list that has not changed in eight months. The whole thing takes forty-five minutes to an hour. It has been done this way since before anyone currently on the team joined.
This process is an ideal first automation. The trigger is time-based and completely predictable. The data sources are stable. The output format never changes. The recipients are always the same. Nothing about this process requires human judgment — it requires human attention, which is different, and human attention is expensive.
This tutorial walks through how to describe a monthly reporting automation to Agenno, including the parts of the description that users most commonly get wrong the first time.
Before you write the description
Spend five minutes answering these questions before you open Agenno. Doing this upfront saves two rounds of clarifying questions and usually means your automation runs correctly on the first attempt.
First: where exactly does each number come from? Not "from Xero" — but which specific report, which field name, which date range. If you pull "total invoiced this month" from Xero, what does that mean precisely? Calendar month? Rolling 30 days? Invoices raised in the period, or invoices with a due date in the period? These distinctions matter because Agenno will be pulling the data programmatically, and a field that looks obvious to a human requires exact specification for a system.
Second: who receives the email? Write down the exact email addresses or confirm that they are all in a named distribution list or group in your email system. If you maintain a recipient list in a spreadsheet, note that — Agenno can pull a dynamic recipient list from a spreadsheet if the list changes occasionally.
Third: what does the email body contain? Is it just a table of numbers, or are there calculated values (percentage changes from last month, variance from forecast)? If there are calculations, you need to specify whether Agenno should perform them or whether the source system already provides them.
Writing the description
A description that works for a monthly reporting automation has three components: the schedule, the data gathering, and the email composition and delivery. Write them in that order.
The schedule component is the simplest: "On the first Monday of each month, at 9am." You can be as specific as you need — "On the third working day of each month" is also valid, though it requires Agenno to understand what constitutes a working day in your context (UK bank holidays? Your company's specific holiday calendar?).
The data gathering component is the most important and the one where the upfront preparation pays off. A description that works might look like: "Pull the total invoiced amount for the previous calendar month from Xero. Pull the total expenses approved in the previous calendar month from our expense tracking sheet in Google Sheets — it is called 'Monthly Expenses Tracker' and the total is in column F of the row matching the month name in column A. Pull the current month's budget figure from the 'FY Budget' tab of the same spreadsheet."
That level of specificity is not excessive. It is what allows the automation to run without ambiguity. If you write "pull our monthly numbers from Xero and the spreadsheet," Agenno will ask you these questions one by one. You will get to the same place — it just takes longer.
The email composition component should specify the recipient list, the subject line format (does the subject line include the month name?), and the structure of the email body. If you want a formatted table with columns and rows, describe it. If you want a simple list of figures with labels, describe that. Agenno will compose the email in plain text by default, but if you need HTML formatting — a table with borders, for example — specify that explicitly.
Handling the "last month" date range correctly
Time-relative date ranges are one of the most common sources of early automation failures. "Last month" is unambiguous to a human reading it in context — you know when the automation is running and you know what last month means — but it requires explicit handling in an automation description.
The safest way to specify this is to be explicit about the calculation: "The previous calendar month, calculated from the date the automation runs. So if the automation runs on 1 September, 'last month' means 1 August to 31 August inclusive." Adding that parenthetical statement eliminates a whole class of edge cases around month-end runs, time zones, and systems that define their own "monthly" reporting period differently.
Similarly, if you need the previous month's name for the email subject line ("Monthly Report: August 2025"), specify the exact format string you want. "Previous month name and year in the format 'Month YYYY'" is more reliable than "last month."
What to expect when it runs the first time
Most monthly reporting automations run cleanly on the first scheduled execution. The most common reason for a first-run failure is that the data source has a slightly different structure than anticipated — a column that has been renamed in the spreadsheet, or a Xero report that uses a different field name than the one specified in the description.
Agenno will surface these failures in the run log with the specific step that failed and the data it was working with. Treating the first run as a test is reasonable: if you want to verify the automation before relying on it for a real month-end report, you can trigger it manually with a test date range and inspect the output before the scheduled run goes live.
One thing worth noting: an automated report looks slightly different from a manually assembled one. The formatting will be consistent because a machine produced it, but it will not have the small human adjustments — the note added in the margin, the footnote about why one number looks anomalous. We are not saying this is a problem; for most operational reports, consistency and reliability outweigh handcrafted formatting. But if your report serves as the primary communication artifact for a board or an external stakeholder, it is worth reviewing the automated version's output format before going fully live.
Extending the base automation
Once your monthly report automation is running, there are two common extensions worth considering. The first is adding a conditional alert: "If the total expenses figure exceeds the monthly budget, also send a separate alert email to the finance manager flagging the overage." This is a simple conditional branch that adds meaningful value without significantly complicating the description.
The second extension is archiving the report data. "After sending the email, write the figures for this month into a named row in the 'Monthly History' tab of the budget spreadsheet, using the month name as the row label." This gives you a growing historical record in a format your team can query manually, without anyone having to remember to fill it in.
The longer your team relies on a process, the more invisible it becomes. Monthly reporting is one of those processes — it runs, people receive it, and nobody thinks about it until the month it does not arrive or arrives late. An automation that runs on schedule, sends a consistent output, and logs a record of every run is strictly more reliable than a manual process that depends on whoever is least busy on the first Monday of the month. That is the bar the automation needs to clear, and for most monthly reporting tasks, it clears it without difficulty.