Review: Letting AI issue receipts in FlowAccount after customers pay online

If you sell courses or products online and customers pay by bank transfer, this probably looks familiar. A payment slip comes in. You open it, approve it, then open your accounting software again to issue a receipt: type the name, enter the amount, hit send, one customer at a time. On a good sales day, that takes a while. And every so often a customer messages you: can I get the receipt in my company's name? I need to claim it.

We sell online courses and ran into the same thing, so we tried handing the job to AI. Today Productize has an AI agent handling the FlowAccount side of our online receipts. It runs on a schedule, with nobody sitting there clicking.

First, where things stand. The company-name document job has been running every 15 minutes since Oct 10, 2026, but no customer has asked for a document in their company's name yet, so no real document has gone out. Even if one did go out today, the buyer's company name would not show on the printed copy. The weekly total job runs for real for the first time on Monday, Oct 12 at 00:05.

Disclosure: the author works at FlowAccount as SME Transformation & AI Lead.

By AI agent we mean an AI that can pick up tools and do the work itself, not just chat. The tools our agent uses come from the FlowAccount AI Connector (MCP), the connector FlowAccount provides so AI can create documents and send emails.

Wiring the systems together is not the hard part. The hard part is this question: with nobody watching, how do you know the agent won't issue a second document for the same purchase? We nearly got that one wrong, and the right answer turned out to live somewhere other than where we first looked.

Part 1Which documents go one per buyer, and which can be a weekly total?

Say a buyer ticks the box for a receipt in their company's name at checkout, because they will claim it from their company. That buyer needs their own separate document by email in the next scheduled check. All the other purchases we book as a single total at the end of the week.

We can split it this way because our sales system, where customers pay by bank transfer and we approve their slip, already gives every buyer an automatic receipt in the buyer's own name the moment we approve it. A company that pays the buyer back needs a document in the company's name, so in FlowAccount we only need a separate document for people claiming from their company. Everything else goes into our books as a weekly total.

Both kinds of document the agent issues, separate and weekly, are FlowAccount cash sale documents (เอกสารขายเงินสด), which record the sale and the payment on one document. It works as a receipt: once the buyer's company name shows on it, the company can use it as the record for paying the buyer back (Part 6 explains why the name doesn't show yet). Here is our policy, word for word:

"ถ้าเค้าไม่ได้ขอเบิกบริษัท ก็ไม่จำเป็นต้องเปิดใน FlowAccount เป็นใบแยก ดังนั้นเวลาเปิดบิลใน FlowAccount สามารถเปิดเป็นยอดรวมสิ้นสัปดาห์ได้ ยกเว้นบิลที่ลูกค้าขอเบิก ต้องเปิดบิลส่งอีเมลให้เลย"

In English: "If they aren't claiming it from their company, there's no need to issue a separate document in FlowAccount. So when we issue documents in FlowAccount, we can issue one end-of-week total, except for bills the customer is claiming. Those we issue and email right away."

What separates the two piles is a checkbox on the payment page: "I need a receipt in my company's name." Ticking it opens fields for the company name, 13-digit tax ID, branch, address, and the email the document should go to.

The weekly total leaves out purchases that asked for a company-name document, so each sale is booked exactly once. Nothing is counted twice.

This two-pile policy is ours. We are not yet registered for VAT, so the cash sale documents we issue are not tax invoices. If you are VAT-registered, the rules on which document goes to whom are different. And if the platform you sell on doesn't give buyers a receipt, you can't copy this split as is. Before you use it, ask your accountant what fits.

Part 2What you need to connect an AI agent to FlowAccount

At first we had no automation at all. We just connected FlowAccount MCP and told the AI, by hand, to issue one demo document. Once we saw it really worked, the question changed: if the AI is going to do this on its own every day, with nobody giving it instructions, what else do we need?

First, a way into FlowAccount, which is the connector we had just tried. Start by turning on the FlowAccount AI Connector (MCP) in your account. How to connect it to Claude is in the help center: How to use FlowAccount AI Connector in Claude. For the terms of use, see FlowAccount's page at flowaccount.com/en/functions/ai-connector.

Second, an AI agent you can schedule to work while you're away. We use Claude Code, Anthropic's AI program, on a server we already keep running. We call it headless: you give it one instruction and let it work through to the end, with nobody typing back and forth. Then cron, the server's scheduler, wakes the job up on the timetable from Part 1.

Third, sales records you control. For us, that's the database behind our own sales system. Each purchase needs a place to write the document number and a place to mark it "issuing". That mark reserves the purchase before the AI is woken up, like signing a sign-up sheet: you can only sign a line that is still empty. So wherever you keep these records, it has to check that the field is still empty and write to it in one step, with no gap for another run to slip in. A database can do that. We haven't tried it on a spreadsheet. If a run creates the document in FlowAccount and then dies before writing the number back, the next run sees the reservation still sitting there and skips it, instead of issuing a second document.

If you sell through an off-the-shelf platform that gives you no place like this, we'll be honest: we haven't tried it on a platform like that.

Last, someone to set it up. Some steps we don't leave to AI, like writing to the sales records and sending alerts, because they have to be exact every time. A short script does those, since a script does the same thing every run. The AI works only inside FlowAccount and never touches our records. We wrote the script ourselves together with an AI coding assistant. If your team has no developer, plan on finding someone for this part, or using the same kind of assistant.

Our machine also has connectors to other systems installed, so we set this job to see only the FlowAccount connector and call only these 5 tools:

• View the company list
• Search contacts (view only)
• Create a cash sale document
• Email a document
• Get a share link

Outside this list, the agent can't call anything. It can't edit old documents, and it can't delete them.

On login: the FlowAccount connector uses OAuth. We log in once during setup, and after that the agent holds a token it uses in place of a password. The token lasts 1 hour, then renews itself with a refresh token (a second code used to get a new token when the old one expires), with no one stepping in.

Rehearse in preview mode first, then run for real

FlowAccount MCP's document-creation tool has a preview mode that returns what the document would look like without actually creating it. Our rehearsal used only that mode. We got one company-name document for 1,900 baht, and a test weekly total of 3,800 baht from other purchases, with the 1,900 baht sale not mixed in. Both matched the amounts in our sales system exactly.

Only once the amounts matched and the duplicate guard (Part 4) was in place did we let it run for real, one full round, in our real FlowAccount account. The agent created the document and emailed it to our own address, and the script wrote the document number and link back, every step complete. Afterward we voided all the test documents ourselves in FlowAccount. We didn't have the AI do it. No customer has received a document from that round.

Part 3Why not let the agent check whether it already issued one?

Because FlowAccount MCP's document search tool (list) once told us there was no document when there was one in the system. Whatever the accounting software's lookup tools return can't be the final word.

During rehearsal, FlowAccount already held one document: the demo we had issued by hand earlier that same day. We called list for cash sale documents twice. The first time with no filter at all, no date range, no search term, which should return every document. The answer was 0. The second time we searched by that document's own number. Still 0. But opening the same document directly by its id found it. So the 0 didn't come from a badly set filter. List simply couldn't see that document. To this day we don't know why.

That 0 knocked over our whole first plan. We had meant for the agent to call list before every document, asking whether this purchase already had one: if yes, skip; if no, issue. Plenty of people would think the same way. The agent has all the tools, so let it check for itself.

Now flip it around. Had we rehearsed while the system was still empty, with no documents at all, list would have answered 0, exactly as expected. We would have believed the check worked and shipped it as is. Then one day a run creates a document but dies before writing the number back, the next run asks list, gets 0 again, and the buyer's company receives a second document for the same purchase. We caught it before that day only because the 0 contradicted something we already knew, not because anything warned us.

We didn't dig further into the cause. We chose to stop relying on that tool instead, so list is not among the 5 tools the live agent gets. We left out the tool that opens one document at a time by its id too, even though it was the tool that found the document list missed. After we voided a document, that same tool still said it was pending, so its status can be stale, and a run that dies before writing back has no id to look up anyway. We stopped asking FlowAccount whether a document had been issued, and moved that question entirely into our own records.

Part 4Mark it in your own records before the AI acts

The picture we designed against is a run that successfully creates the document in FlowAccount, but the script dies before writing the number back. If that purchase's record is still empty, the next run sees no document yet and issues another one.

The fix is the sign-up sheet from Part 2. Before the AI is woken up to do anything in FlowAccount, even once, the script writes "issuing" on that purchase's record. It can only write it on a purchase that has no document number yet and that nobody has marked.

For one purchase, the order is:

1. Select: the script pulls only purchases that have no document number and no "issuing" mark.
2. Reserve: the script writes "issuing" with a write that only succeeds if those fields are still empty. If it can't, it stops right there and doesn't wake the AI.
3. Create: the AI creates the cash sale document in FlowAccount, sends the email, gets a share link, and replies with the document number.
4. Write back: the script writes the document number and link back to the same record, then posts to Discord.

If a run breaks partway, that purchase stays marked "issuing", and no run picks it up to try again on its own. If FlowAccount replies with an error, the script also posts it to Discord.

From there it's a human's job: open the FlowAccount website and look for that purchase's document. The website doesn't go through MCP's list, and it's the same page where we saw and voided the early test documents with our own eyes. If you find the document, copy its number into the record yourself. If not, remove the "issuing" mark, and the next 15-minute run will issue it.

It sounds slow, but we chose it on purpose. A document that reaches the customer a little late is something you can apologize for. Sending two and then chasing one down to void it is far messier.

The weekly total job works the same way, except it marks every purchase for the week in one go. After the AI creates the document, the script also checks the amount FlowAccount returns against the amount in our sales system. If they don't match, it doesn't write the document number back. It leaves the purchases marked and posts to Discord, so a person can open the FlowAccount website and decide whether to keep or void that document.

What testing told us, and what we still don't know

Seeing the system issue documents doesn't mean the duplicate guard works. So we planted a test purchase already marked "issuing" and let the job run. It was skipped at step 1 (select), so it never reached step 2 (reserve).

So this test confirms only that a purchase already marked never gets issued again. The condition in the reserve step has never actually had to stop anything. It is the backup for the day two runs overlap, so only one of them can reserve the purchase.

Part 5How we know the system is still working

Picture a customer ticking the company-name box at 10 a.m., while the token has failed to renew since 3 a.m. The agent can't reach FlowAccount, so that document never goes out. Nothing turns red, nobody notices, until the customer messages to ask. A system that runs on its own while nobody is watching can fail silently like this, and login is the part we worry about most.

So we set up another small job. Every hour, Haiku (Claude's small, cheaper model) asks FlowAccount MCP a single question: which company are you in right now? The answer must match our company name exactly, character for character. If it doesn't, an alert goes to our Discord channel. On a day the login stops working, say the refresh token expires, the question can't be answered and the alert fires. And if it answers with a different name, the agent is in the wrong company, which is just as scary.

And how do we know the alert itself isn't broken? We broke it on purpose once, and the alert really did land in Discord. An alarm we have never seen go off is an alarm we can't trust to go off.

One more signal comes free from the main job. Every company-name document issued successfully posts to the same channel. Open Discord and you can see how many went out today, and which ones.

Part 6What isn't done yet, and where to start

The part that hurts most: the buyer's company name doesn't show on the printed document yet, even though that's the whole reason the customer asked for it. The company details reach FlowAccount in full, but the print template for this document type doesn't show the buyer section yet. It has to be fixed in the template settings page, so that's the first thing we need to close.

The rest is lighter. Payments are recorded as cash for now, because we haven't linked the company bank account in FlowAccount yet. Once it's linked, they'll switch to bank transfer. We don't know yet how long the refresh token lasts. We're watching, and the hourly check is exactly what will tell us when that day comes. And if the script simply dies partway, the purchase stays marked "issuing" with nothing to alert anyone yet. Someone has to notice and fix it the way Part 4 describes.

If you want to try it yourself

The first thing we recommend doesn't touch AI at all. If you have your own system for recording purchases, add a place to write the document number and a place to mark "issuing" on each purchase. You can do it today, and while your team still issues documents by hand, whoever is about to issue one marks it first, so nobody else issues it again. If you sell through an off-the-shelf platform, we haven't tried that, but at the very least keep your own list of which purchases already have a document, and check it before issuing every time.

Typing the name, entering the amount, hitting send: almost all of it can go to an agent. The one thing we kept for ourselves is the memory of which documents have already gone out.