Turning Unprocessed freee Accounting Transactions into a Monthly Reconciliation Run: 7:30 on the 5th, 3 Categories, and a Cap of 15 Items Handed to a Human

Good morning, まさきん here.

Unprocessed transactions pile up in freee Accounting, and reconciliation goes nowhere. That was the state of things on my end for a while. So I settled on a design that turns it into a once-a-month automated run, and I am noting down what I decided.

Note: this information is current as of the publication date. Please check the official sites for the latest conditions.

The unprocessed transactions did not move 6 times

I keep the books for a small side business in freee Accounting, a Japanese cloud accounting service. Bank and card transactions are imported automatically. All that should be left is to check and register them.

Yet about 18 unprocessed transactions were just sitting there. I look at the count in my weekly check. It had not moved 6 times in a row.

I look every week and it still does not shrink. I felt that “I was busy” could not explain this. There is a time set aside for looking, but my hands are not moving.

The cause of stalling is the unsure transactions

Maybe the reason I am stuck is not the sheer number. That was my thinking.

Among the 18, some look like they could be registered right away. Others make me stop and think every time I open them. Is this a business expense or a household one? Where is the receipt? That kind of transaction.

When one unsure item sits at the top, my hands stop there. Even the easy ones behind it get left along with it. So I came to think that lining them up all mixed together is the problem.

On sorting transactions, there is also my post on sorting mall card statements when the tenant name does not appear. This time the topic comes before that: ordering and how to split.

Division of roles with the existing matching setup

I have already written up, in a separate post, a setup that uses AI to match transactions against emails. That is my setup for matching side business expenses with AI. I will leave the matching method to that post.

What this post covers is the layer outside it. When does it run? Where does it run? From which point is it handed to a human? It is about deciding these three things.

Even with a matching setup, it does not last if the trigger is “when I feel like it”. My 6 weeks were exactly that. So I am making it a scheduled run.

Bookkeeping is daily in principle

Let me confirm a premise first: whether it is acceptable to bundle things into once a month.

The National Tax Agency’s “Tax Information for Daily Life” says the following. To calculate income correctly and file a return, you need to record the status of daily transactions. Books and documents must be kept for a set period. The principle is, after all, daily bookkeeping.

So I do not think “bookkeeping once a month is fine”. Importing transactions and the weekly check will continue as before. What becomes monthly is the occasion for making decisions on the unsure transactions.

What I decided for the monthly reconciliation run

Here is what I decided, listed first.

1. It lives on my home Mac
2. It runs at 7:30 a.m. on the 5th of each month. The first run is the 5th of next month
3. Unprocessed transactions are split into 3 categories
4. Items that can be confirmed become one summary task per month
5. Unsure transactions and loan repayments become one task per transaction
6. Transaction IDs prevent duplicates, and the cap is 15 per month
7. A human does the registration in the accounting software itself

All of these are at the “decided” stage. Nothing is implemented yet, and there are no results from running it. I cover that in the section on upcoming work near the end.

The 3 categories of transactions

The core of the design is how transactions are split.

Items that can be confirmed do not get a task each. They are bundled into one. If I split transactions I have no doubts about into 10 tasks, it only clogs the task list.

Unsure transactions, on the other hand, are split one by one. I want a form where all I have to think about is “what do I do with this one item”. If other transactions are lined up before and after it, I suspect my hands would stop again.

I made loan repayments a separate category because what needs checking differs from other expenses. They also come without fail every month. Rather than mixing them in with the unsure ones, I am giving them a fixed task format.

Preventing duplicates and the cap of 15 per month

Making one task per item raises two concerns.

One is duplication. If the run fires this month while last month’s task is still open, a second task for the same transaction gets created. So I use the transaction ID as the marker. If a task with the same ID already exists, no new one is created.

The other is volume. If dozens of unsure transactions turn into tasks at once, that alone kills any wish to open them. So for the ones raised as individual tasks, I set a cap of 15 per month.

There is no deep basis for the number 15. It is a guide for keeping the task list from filling up. If it does not fit once it is running, I intend to revisit it.

The line: a human does the registration

What I leave to the AI stops at matching and suggesting. The registration in the accounting software itself is something I do on screen.

There are two reasons. One is that it fits how freee Accounting itself thinks. The official help describes a flow where you review the content inferred for a transaction and then register it.

There are also two kinds of auto-registration rules. According to the official help, you can choose whether the configured content is auto-filled as a transaction or auto-registered. The former is “infer” and the latter is “register”. My 3 categories may simply be this distinction copied into the shape of tasks.

The other reason has to do with the API. Even if you create a deal through the API, the transaction side stays unprocessed. User reports say there is behavior like that. I have not confirmed whether it is still the case.

So I did not build on the premise of “finishing reconciliation with the API alone”. With a design where a human does the final push on screen, I think it is less affected by this point.

It lives on my home Mac

I decided the run will live on my home Mac. I will not create a scheduled task on the cloud side.

The flow has three stages. launchd on macOS wakes things up at the set time. The shell script it launches does the preparation. Inside that, Claude Code runs headless. Headless means sending a single round of instructions with claude -p without bringing up the interactive screen.

Apple’s developer documentation explains time-based scheduling in launchd. If the machine was asleep at the scheduled time, the job runs when it wakes. If it was powered off, the job does not run until the next scheduled time. That was the gist.

However, this document is an archive that has not been updated in a long time. Whether current macOS behaves the same way is something I need to confirm on my own machine. I will also check how to write the “5th of every month” setting when I implement it.

On the limits of scheduled execution, there is also my post on the Cron Trigger limit on the Cloudflare Workers free plan. I get the feeling that where to run something is what matters first, every single time.

Why decide the location first

While working out this design, I tripped over one thing.

From the cloud-side working environment, the folders on my home Mac were not visible. I wanted to check how the existing setup works, but could not reach it. I did the checking through a different route.

What I learned here is the order. Unless you decide the location first, even checking does not move forward. Before what to automate, pin down what is visible from where. The next time I build something similar, I will start from there too.

This kind of review of “where a system lives” may apply just the same to fixed household costs. Things that go out every month without fail, such as phone and internet bills, are often left running in the shape they were first set up in.

The monthly schedule

Here is how I laid out the flow of a month.

The 5th is a little after the start of the month. If it runs at 7:30 in the morning, I can open the tasks that same day.

Retention periods for books and household-related expenses

Most unsure transactions, when you get down to it, arrive at two questions. Is there evidence left? Can it be called a business expense?

On the evidence side, the retention periods are fixed. The National Tax Agency’s “Tax Information for Daily Life” (Reiwa 8 edition) has a table of retention periods for blue return filers.

This is why I put transactions with no receipt found under “needs a decision”. I do not feel it is something to wave through with “I can look for it later”.

On whether it can be called a business expense, the idea of household-related expenses comes in. According to the National Tax Agency’s Tax Answer pages, household expenses do not count as necessary expenses. However, a single expense can relate to both the household and the business. That is a household-related expense.

Only a limited portion counts as a necessary expense: the amount that can be clearly separated, based on transaction records and the like, as having been directly needed for the business. That is how it is written. I placed this in the category a human looks at, rather than deciding it on the AI’s suggestion alone.

Work from here

Two pieces of work remain.

1. Implement it and run this month’s data through as a dry-run (by the end of the month)
2. At the very start of implementation, confirm whether there is a route for reading emailed receipts from the Mac side

A dry-run is a way of testing that shows only the results without actually creating tasks. Before going live, I will see whether the way the 3 categories split matches my own sense.

I put the second one first because of the experience of tripping over the location. Matching needs the emailed receipts. If it turns out they cannot be read from the Mac, I will have to fix the design.

The first run is planned for the 5th of next month. I will write up the results separately once I have numbers.

Common mistakes and pitfalls

Lining up unsure and easy transactions all mixed together. I suspect this is what my 6 weeks were. When I stop at the first item, even the easy ones behind it are left.

Making every single item its own task. If you split out even the ones you have no doubts about, the number of tasks is overwhelming. I chose to bundle the confirmable ones into one.

Putting off the location. If you design without confirming what is visible from where, you stall at the checking stage.

Mistaking a monthly run for “monthly bookkeeping”. The official principle is daily bookkeeping. The monthly run is an occasion for decisions, not a way to lower how often you keep books.

Building on the premise that the API alone finishes it. There are reports that the transaction stays unprocessed after registration. I think it is safer to leave room for a human to finish on screen.

• Have you counted how many unprocessed transactions there are and how many weeks they have not moved?
• Have you worked out whether the cause of the stall is the count or the unsure transactions?
• Have you confirmed that the needed files and emails are visible from where the run will live?
• Are the confirmable items and the items needing a decision made into different kinds of tasks?
• Have you chosen a marker (such as the transaction ID) so the same transaction never gets two tasks?
• Have you set a cap on how many items are handed to a human per month?
• Have you drawn the line on who does the registration in the accounting software?
• Is the plan built on continuing daily bookkeeping and the weekly check as before?

Frequently asked questions

Q. Is reconciling once a month really all right?

The National Tax Agency’s wording is “record the status of daily transactions”. I have not found any official statement saying once a month is fine. So importing and the weekly check continue. Only the occasion for deciding on unsure transactions becomes monthly.

Q. Why 7:30 a.m. on the 5th of each month?

It is placed as a morning a little after the start of the month. If it runs in the morning, I can open the tasks that same day. If it does not fit, I intend to revisit it after running it.

Q. Are auto-registration rules alone not enough?

For transactions with a fixed shape, I think rules fit well. But what was left on my end was the unsure transactions. I feel there needs to be an occasion where a human looks, one by one, at what rules cannot settle.

Q. Why not let the AI go as far as registering?

Because the flow in the official help is to review the inference and then register. I also wanted to keep the final call on business versus household for myself. The AI goes as far as matching and suggesting.

Q. If the home Mac is asleep, will the run fire?

According to Apple’s document, if the scheduled time arrives during sleep, the job runs on wake. If the machine was powered off, it does not run until the next scheduled time. It is an old document, so I will confirm the behavior on current macOS when I implement it.

Q. How did you settle on the cap of 15 per month?

It is a guide for keeping the task list from filling up. It is not a number with a solid basis. I will adjust it after running it.

Q. How much effect has it had?

I do not know yet. This post is a memo from the stage of having settled the design. The first run is planned for the 5th of next month, so I will write about results after that.

Q. Does this setup decide whether something can be expensed?

No. All the setup does is split transactions and hand them to a human. For final tax judgments, please check with a tax accountant or the tax office.

Official sources I referred to

• Bookkeeping, record retention, and blue returns (National Tax Agency, Tax Information for Daily Life)
• No.2070 The blue return system (National Tax Agency)
• No.2210 Basics of necessary expenses (National Tax Agency)
• Registering deals from automated bookkeeping (freee Help Center)
• Setting auto-registration rules for transactions (freee Help Center)
• Scheduling Timed Jobs (Apple Developer Documentation Archive)
• Run Claude Code programmatically (Claude Code documentation)

Summary

My view is that the unprocessed transactions did not move because unsure ones were mixed in. So the confirmable ones get bundled, and only the unsure ones are handed to a human one at a time. The plan is to run it on my home Mac at 7:30 a.m. on the 5th of each month.

I have only settled the design and have not run it yet. If your hands have stopped in front of a pile of transactions, how about first counting “how many are the unsure ones”?

The money that goes out every month without fail might also look different once you split it up and look it over in the same way. If you like, open the statement for fixed costs such as your phone bill too.

This article contains affiliate advertising. If you sign up for a product or service through a link on this site, we may receive compensation from the partner company. The site operator is also an employee of Rakuten Group and may receive compensation through an employee referral program. The content and opinions here are based on the operator’s own experience and research regardless of any advertising relationship, but please read with the above in mind. See the Disclaimer & Affiliate Disclosure for details. Disclaimer & Affiliate Disclosure

This article includes machine-translated content. Please check the official Rakuten Mobile multilingual page for exact terms.

If you have concerns about Rakuten Mobile coverage or signal quality, you can consult through the official signal improvement request form .