How I Built My Own ERP with AI and Avoided Four Costly Accounting Pitfalls

The Dream That Wouldn't Die

For years, I wanted to build my own ERP system. I studied computer science in college—operating systems, databases, software engineering—but after graduation, I barely wrote a line of code. The blueprint was in my head, but my fingers froze at the keyboard. The idea stayed just an idea.

Work pulled me deeper into ERP anyway. I joined digital transformation projects at large enterprises, then moved to a domestic ERP vendor, and later landed at a Big Four accounting firm. Through all those projects, I absorbed how business processes flow, how accounting entries are made, and the chaos that happens before go-live. Slowly, a complete ERP model took shape in my mind.

I knew how the business should flow and how vouchers should be generated. Balancing the reports was never the hard part. But a model in my head isn't a system. Without coding skills, it stayed theoretical.

Then AI arrived, and the dream became real.

From Blueprint to Working System

Today, that system is in internal testing. Purchase, production, and sales documents automatically generate accounting entries. Those entries roll up into account balances, and the balances produce a balance sheet and income statement. I even wrapped the core modules as MCP servers, each with dozens of tools that map to ERP functions. Hook them into WorkBuddy, and I can check inventory, create purchase orders, or pull a profit statement just by chatting.

But this isn't a smooth success story. I hit four major pitfalls, and each one cost me time, sanity, and a few sleepless nights. If sharing them helps someone else skip a step or two, it's worth it.

Pitfall 1: Letting Each Module Do Its Own Accounting

When I started, I poured most of my energy into the UI and workflows. Button placement, field dependencies—I thought that was the real craft. It wasn't until I dug deeper that I realized the real challenge was turning business actions into accounting language.

Purchase receipts need to record inventory and accounts payable. Production material issues move raw materials to work-in-progress. Sales confirmations trigger revenue and receivables. Three business actions, three sets of debit-credit logic.

My first version had each module generate its own vouchers. Everyone did their own math, and it collapsed quickly. Account balances didn't match. Purchasing said payables were one number, finance said another, and everyone was sure they were right.

So I restructured. Modules no longer create vouchers. They only emit business events, and a central voucher engine translates them. Each document type has its own account mapping rules. A purchase receipt comes in, and the engine debits inventory and credits payables. A sales confirmation triggers revenue and receivables. All vouchers write to the same account balance table, and the balance sheet and income statement are just read-only projections of that table.

The essence of integrated business and finance isn't bolting modules together. It's a translation pipeline from business actions to accounting language. The translation rules must be centralized and configurable, not scattered across modules speaking different dialects.

Once I made that change, adding new modules was easy—just attach a mapping, and the vouchers appear. No more begging finance to reconcile.

Pitfall 2: Mixing AI Models Like a Kid in a Candy Store

The code was written by AI, but the model choice was a trap. At first, I let different models handle different modules, thinking I'd get the best of each. Big mistake.

Model A's interface style clashed with Model B's. Naming, structure, error handling—they had completely different personalities. Fixing A broke B, and fixing B broke A. Bugs outnumbered features.

Worse, I let different models take turns editing the same logic. One model's context didn't carry over to the next, so it rewrote things its own way, and the logic got tangled. Each piece looked fine alone, but together they didn't work. Debugging was torture because every segment seemed correct.

After testing several, I settled on GLM5.2 and used it for the entire project. One model, one style. Changes became predictable, and when something got messy, the same model could pick up the thread.

My advice: don't be greedy. One good model beats three smart ones. I could have saved myself tens of thousands of lines of deleted code if I'd learned that earlier.

Pitfall 3: No Version Control Until It Was Too Late

In the early days, I didn't use Git properly. Files piled up in folders with names like "final," "final2," "real final," "real final no changes." Then a big refactor broke the voucher engine's core logic. I tried to roll back and found no clean version. I had to rewrite.

That happened more than once. Each rewrite wiped out two or three days of work, and worse, it drained my motivation. By the second rewrite, I started doubting whether this project was even possible—and it was burning tokens.

Finally, I got serious about Git. Now I create a branch for each phase, keep the main branch for tested code, and let feature branches run wild. If something breaks, I can revert in ten minutes. I also made a habit: before ending the day, merge stable work into main, leave unstable stuff in a branch overnight.

Without version discipline, a personal project is like coding on a cliff. You think you're saving time, but one wrong move erases everything. When you're solo, there's no one to catch you.

Pitfall 4: MCP Interfaces That Hid Frontend Calculations

Once the system ran, I got hooked on MCP. Traditional ERP menus felt clunky. I wrapped purchasing, production, sales, and finance into MCP servers, each with dozens of tools. Want to check stock, create a PO, or pull a profit statement? Just type it in WorkBuddy.

I learned the hard way that tool granularity matters. Too coarse, and the model can't tell what you want. Too fine, and the tools blur together. I ended up splitting by business action—one action, one tool, with clear names.

But the sneakiest trap was this: I put some calculations outside the backend interface, thinking the frontend could handle them. Subtotals, taxes, document summaries—all computed in the UI. That worked fine in the GUI because the frontend executed the math.

But conversational calls don't run frontend code. They just pass parameters and get results. So the numbers came out wrong. Voucher amounts didn't match, and reports disagreed with the business data.

This was the hardest bug to find. The GUI showed correct numbers. Only the chat interface was off. I stared at the same transaction—GUI one number, chat another—and couldn't figure out why.

So I upgraded the API. Every calculation, no matter how small, moved into the backend. The frontend and chat layer only pass parameters and display results; they never touch the math. I also added double-check validation: the same number is computed via two paths, and if they don't match, it's blocked before hitting the ledger. Double insurance.

After that, data finally stabilized. Numbers from chat, GUI, and reports all agreed. The lesson: MCP interfaces must be fully backend. If the frontend does the math, conversational calls will silently break. The interface has to stand alone, because chat won't fill in missing frontend logic.

The Real Takeaway for Accounting and AI

AI loosens the reins on coding, but it doesn't loosen the reins on understanding your business. Plenty of people think AI can figure out the system for them. It can't. AI writes the code; you still have to think through the business. That gap is where the pitfalls live.

None of these four traps were one-and-done. Each cost me time, energy, and a few moments of staring at the screen wondering if I'd lost my mind.

In the end, AI provides the muscle, but judgment is still yours. It hasn't made development easier—it's just made it possible for one person to shoulder the weight of enterprise software. The price is that every decision is yours alone, and there's no one to hit the brakes.

That long-held dream is now running in internal testing. It's not perfect—modules need polishing, reports need tuning, and sometimes the chat mishears me. But it actually generates a balance sheet on its own. And that's enough.