What each warning email means, and what to do about late statements, oversized packages, and connection problems.
The automation is designed to tell you, by email, whenever it needs you. This page goes through each situation: what the email means, and what to do. Remember that every email from the automation has a subject starting with [Impuestos MX].
On the 7th, if the automation hasn’t found the bank’s monthly statement in the folder, it reminds you once.
What you do:
If you can’t get the statement in time, you don’t need to do anything: on the 8th the automation sends whatever is in the folder (after the usual 12-hour hold), telling the accountant the statement will follow. When you eventually have it, forward it yourself as a reply on the same email thread — the automation will not send it for you at that point.
If by the 7th there is no folder for the month at all, you get one email saying so.
What you do:
MM-YYYY (for example 08-2026 for August 2026).The automation finds the folder on its next pass and carries on normally.
Nothing sends, and nothing is wrong — the automation matched the statement’s period and saw it isn’t this month’s. Run the status action (see the Controls page) if you want confirmation; its email names the period it found. Add the correct month’s statement and things proceed.
A file was added to the folder after the package went out. The automation tells you once per file and deliberately sends nothing further on its own.
What you do:
Email carries about 25 MB; if the zip plus summary would exceed that, the automation refuses to send and the run fails rather than letting the email bounce. The fix is to slim the folder down.
What you do:
If sends and notification emails stop arriving when you expect them, the automation may be unable to reach Dropbox or the email account. Its runs are listed on the repository’s Actions page on GitHub — a red mark means a failed run.
For Dropbox problems there is a built-in checker: run the diagnose action (see the Controls page for the steps). It tests the stored Dropbox credentials and prints, in the run’s log on that same page, exactly which of the three values is wrong and how to fix it — without ever revealing the values themselves. The Dropbox connection doesn’t expire on its own; it only breaks if the app’s access is revoked in Dropbox’s own settings, in which case a new token has to be created and stored again as described in the repository’s README.
Sending and reading email uses a Gmail app password. If Google revokes it (for example after a password change), create a new app password in the Google account’s security settings and store it in place of the old one. All credentials live only in the repository’s Settings → Secrets and variables → Actions page on GitHub — never in any file, and never in these guides. The repository’s README has the full, step-by-step setup for both credentials.
The schedule isn’t to-the-minute: runs happen hourly during the first 12 days of the month and twice a day after that, and the scheduler can run some minutes late or occasionally skip a slot. An hour or two of slack is normal; the next pass catches up. If you don’t want to wait, run the check action to force a pass right now.
Whenever you’re unsure — after changing anything, or just to see it work — run the dry-run action on a finished month (Controls page). It builds the real package and emails it to you alone, with the exact recipients and subject a real send would have used, and changes nothing. The accountant never sees a dry run.