Yes, you can build an ERP prototype with AI coding tools, often quickly: screens, forms, a database and basic workflows. A production ERP is different. It must post balanced accounting entries every time, enforce controls and audit trails, migrate and reconcile real data, stay secure and keep working through years of change. AI tools speed up that work; they do not replace the engineers accountable for it.
This guide is written for founders, finance leads and operations managers who have tried an AI coding assistant, seen a working order screen appear, and wondered whether they still need a development partner. The honest answer depends on what you intend the system to do. If you want to understand the wider build-your-own route, read build your own ERP; if you want a production system built for you, see our custom ERP software page.
What can AI coding tools do well in an ERP project?
AI coding tools are good at producing code that follows a clear pattern, and much of an ERP follows clear patterns. Where they help most:
- Prototypes. A clickable version of an order, job or stock screen to test with users before anyone writes a specification.
- CRUD screens and forms. Lists, detail views and validation for master data such as customers, items and suppliers.
- Reports and exports. Queries, report layouts and CSV or Excel exports, once the data model is right.
- Integration scaffolding. Client code for documented APIs, mapping functions and test fixtures.
- Tests and documentation. Drafting unit tests, test data and technical notes for engineers to review.
- Working inside existing platforms. Vendors are adapting too. Microsoft's Business Central developer documentation (checked October 2026) includes AI agent tools for AL development and points to BC-Bench, a benchmark for evaluating coding agents on Business Central AL tasks.
Used this way, AI tools shorten the distance between an idea and something users can react to. That is valuable, especially early.
What do AI coding tools get wrong in an ERP?
The risk is not that the code fails to run; it is that it runs and is subtly wrong. ERP errors surface weeks later, in a reconciliation or an audit, not on screen. The areas that need engineering judgement:
| Area | What a prototype often does | What production needs |
|---|---|---|
| Accounting correctness | Saves an invoice and updates a balance field | Double-entry postings that always balance, period locks, reversals instead of edits, consistent rounding and currency handling |
| Controls | Any logged-in user can do anything | Role-based permissions, segregation of duties, approval limits, maker-checker on sensitive changes |
| Audit trail | Overwrites records | Immutable history of who changed what and when, especially for financial and master data |
| Concurrency | Works for one user | Correct behaviour when two people allocate the same stock or post to the same period at once |
| Data migration | Starts with an empty database | Cleansed, mapped, reconciled opening balances and open transactions |
| Security | Default settings, secrets in code | Authentication, authorisation checks on every action, input validation, secret management, logging and patching |
| Change over time | Regenerated when something breaks | Versioned, tested code that a team can change safely for years |
None of these are impossible for AI-assisted development. They require someone who knows what correct looks like and checks it.
Accounting rules are business rules, not code patterns
An AI tool will write a function to post an invoice. It will not know that your business recognises revenue on delivery rather than on order, that a credit note must reference its original invoice, or that a closed period must reject backdated entries. Those rules come from finance, and someone has to turn them into specifications and tests.
Security needs a standard, not a feeling
Generated code can look tidy and still miss an authorisation check on one endpoint. Use a recognised baseline, such as the OWASP Application Security Verification Standard, and review against it. Our security and data protection page describes how we approach this on client systems.
Migration is where prototypes meet reality
A prototype built on clean test data has never met a supplier entered three ways or a negative stock balance. Migrating real data, reconciling it and cutting over at a period start is detailed work; see our ERP data migration plan.
Who should build an ERP with AI tools?
It depends on the stakes. This decision table is a starting point.
| Situation | Reasonable approach |
|---|---|
| Testing an idea, no real money or stock flows through it | Build a prototype yourself with AI tools |
| Internal tool beside your accounting system, low risk, few users | AI-assisted build with an experienced developer reviewing |
| System that posts to the ledger, controls stock or handles customer money | Engineering team using AI tools, with finance-defined rules and tests |
| Multi-entity, regulated or audited operation | Experienced ERP team; AI tools used under review, never unsupervised |
How do engineers use AI tools on a production ERP?
On serious projects AI tools sit inside a normal engineering process, not instead of one. A sensible pattern:
- Humans define the rules. Finance and operations agree posting rules, approval limits and edge cases in writing.
- Engineers design the data model. Ledgers, entities, items and documents are designed deliberately, because everything else depends on them.
- AI tools draft, engineers review. Generated code goes through the same review, tests and security checks as any other code.
- Tests encode accounting truth. Automated tests prove that every transaction type balances, period locks hold and permissions are enforced.
- Users test real scenarios. Staff run their actual week through the system before go-live.
What is the role of engineers when AI writes much of the code?
Engineers become responsible for the parts AI tools cannot judge: what the system should do, whether the code does it, and whether it will keep doing it. On an ERP that means:
- Turning business rules into specifications and tests. "Invoices post on delivery" becomes a rule, a set of test cases and a check that every path respects it.
- Owning the architecture. How entities, ledgers, documents and permissions relate is decided once, deliberately, and protected from accidental change.
- Reviewing every change. Generated code is read, questioned and tested like any other contribution. A suggestion that compiles is not the same as one that is correct.
- Handling the edge cases. Partial deliveries, credit notes against part-paid invoices, currency revaluation, stock returned to a different warehouse.
- Running the system. Deployments, monitoring, backups, incident response and security patching do not stop after launch.
- Being accountable. When the auditor asks why a balance moved, someone has to explain the code that moved it.
AI tools change how fast that work gets done, not whether it needs doing.
Where does AI speed up ERP delivery most?
The biggest gains tend to come early and at the edges, the smallest in the financial core.
| Stage | Typical AI contribution | Human focus |
|---|---|---|
| Discovery | Fast prototypes users can react to | Agreeing rules and priorities |
| Build: screens and reports | Drafting forms, lists, queries and layouts | Review, usability, permissions |
| Build: posting and controls | Drafting code and test cases | Defining rules, verifying every path |
| Integrations | Client code, mapping functions, test fixtures | Error handling, retries, reconciliation |
| Migration | Transformation scripts, profiling queries | Data ownership decisions, sign-off |
| Support | Explaining code, drafting fixes | Root cause, regression tests, release |
Checklist: is your AI-built ERP ready for real use?
- Every financial transaction creates balanced double-entry postings
- Closed periods reject new and backdated entries
- Posted documents are reversed or credited, never edited or deleted
- Roles and permissions are enforced on the server, not just hidden in the interface
- Sensitive changes (bank details, prices, credit limits) need approval and are logged
- An audit trail records who changed what and when
- Concurrent use has been tested for stock allocation and posting
- Opening balances and open items have been migrated and reconciled
- Security has been reviewed against a recognised standard
- Backups are taken and a restore has been tested
- Someone other than the original author can understand and change the code
If several boxes are unticked, treat the system as a prototype. That is not a failure; a good prototype is a strong input to a production build.
When is building it yourself the wrong approach?
It is the wrong approach when the system will hold your financial record, when auditors or regulators rely on its output, or when several people depend on it daily and nobody can support it. It is also wrong when the underlying need is standard: a packaged ERP or accounting product may already do the job with less risk.
Illustrative scenario
An operations manager at a small distributor uses an AI coding assistant to build an order and stock tracker over a few weekends. It works well for her team. Problems start when finance wants it to create invoices: stock values do not match the ledger, two users can allocate the same pallet, and nobody can tell who changed a price. The prototype has done its job, proving the workflow. The sensible next step is a production build that keeps the screens users like and rebuilds the posting, controls and data layers properly.
How to start
If you have a prototype, keep it: it is a clear statement of what users want. Write down the rules it does not yet enforce, the data you would need to migrate and the systems it must connect to. Our software requirements brief template helps. If you are deciding whether a pilot proved anything, our guide on how to evaluate an AI pilot applies the same discipline. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, and our engineers use AI tools under review where they speed delivery. Discuss the project, or read about our ERP module development service.