Month-end close became a system on round two — a new store opened, and the procedure absorbed it

2026-06-11 ／ Vol 12 ／ draft at the time of publishing

In Vol 11 I wrote that month-end close had quietly become "just verifying". That was May 17. Two weeks later, on June 1, the close for May arrived — the second month-end under the current automated setup.

After round one, my impression was "it worked." After round two it's different: this has become a system. That's today's story.

What made round two different from round one

Round one, honestly, was partly improvised on the spot. The procedure ran, but a good half of the runbook still lived in my head.

Round two was the opposite: run the documented procedure, and write every exception that comes up back into the runbook. And this past month delivered its exceptions right on schedule.

Exception #1: a second Square location had appeared

The biggest one was Square. In late May I opened a second location — one more place to sell in person, a perfectly ordinary business event.

The problem was on the aggregation side. The monthly Square sales pull was hard-coded to look at the original single location. When it was built there was only one location, so it was correct. Left as-is, the new location's sales would have silently dropped out of the books.

To be honest, I hadn't noticed the stale assumption myself. The very person who opened the store had forgotten to update the premise of his own aggregation. It surfaced in the pre-close check, and the fix was structural: first enumerate all active locations, then pull payments per location, then sum everything. June 1 was the first close to run through the revised procedure. The new location has only seen opening-test payments so far, so the monetary impact is near zero — which is exactly why I'm glad the leak got plugged while the numbers were still tiny.

Two new rules entered the runbook

Rule 1: before importing, look at what is already in the books. Before any new journals go into Yayoi, reconcile against what has been entered for the target month. Yahoo! Shopping sales, for example, are posted in three closings — the 10th, the 20th, and month-end. Import without checking which closings are already in, and you get double posting the boring way. This time the check showed only the month-end closing was missing, so only that one was added. "Reconcile, then import" is now pinned to the top of the procedure.

Rule 2: "storage-only" data goes to its proper archive. Raw data that never becomes a journal entry but should be kept — order exports, the product master, Yamato's freight detail — used to get dropped into the tool's input folder and left there. The input folder is a working copy at best; the real archive lives elsewhere (a set of folders I call "source data"). From this round, "did it land in the proper archive?" is a checklist item.

And one iron rule came out of an actual mistake: keep the original downloaded file name, always. Trying to be helpful, I once renamed a file to match an older naming convention while moving it — and created a duplicate, because the same file was already archived under its original name. Had I left the name alone, "a file with this name already exists" would have flagged the double download on the spot. Sometimes not being clever is the safer move.

The Yayoi import settled into shape — but the last button is mine

The final step of the close is importing the generated journal CSV into Yayoi Aoiro Online. This also locked in this round.

One technical aside: an AI cannot drive the browser's file-picker dialog. The picker is an OS-level dialog, outside the reach of browser automation. The workaround is to encode the file as a base64 string and inject it directly into the page's file input. Together with a clipboard-based variant, it has become a standard move in my automation toolbox.

And the final "start import" button is always pressed by me. Committing entries to the books is the point of no return, and there is no reason to hand that to the AI. I check the confirmation screen — number of entries, date range, "cannot import = 0" — and I press it. One human button, kept deliberately inside the system.

The card-statement task on the 21st is becoming a system too

The close doesn't end on the 1st. On the 21st there's the PayPay Card statement import. It ran for the first time in May, and the most confusing part got written down as an explicit rule: what the 21st-day task imports is the previous month's card usage, from the 1st through the last day. Card usage months and billing months are offset, and unless that's in writing, you re-derive it in your head every time. Re-deriving every time is where mistakes live. This month's 21st should run on a plain re-read of the runbook — and if that prediction misses, that becomes an article too.

"Becoming a system" means absorbing exceptions

After round two I can finally put words to what "it became a system" means. Not that the procedure stopped changing. It's that when a new exception arrives, the runbook absorbs it, and from the next round it is no longer an exception. This round, "a store was added" turned into the general rule "enumerate all locations and sum," and a near-miss double posting turned into the first line of the procedure: reconcile, then import.

A system is not a procedure that never changes. It is a procedure whose way of changing has been decided.

One more thing. The runbook no longer lives in my head. It lives in the repository's documents and in the AI's (Claude's) memory. On June 1, all I said was "run the May close" — the closing-date distinctions, the archive rules: the one who remembered them first was the AI, not me.

To avoid ending on a too-clean note: not everything ran smoothly. One account name generated by the tool was off by one word from the name Yayoi expects, so every import needed a manual conversion step — a small splinter that stayed in for weeks (as it happens, I fixed the tool today). Becoming a system doesn't end maintenance. What it does is reduce the fix to a single place — that's the accurate version.