When an AI-native ERP is the wrong answer
Seven situations where we tell people not to do the project, and what to do instead.
I implement AI-native ERP for a living. Campfire, Rillet, DualEntry. Eight implementations, entities live across the United States, Canada, the United Kingdom, Mexico, Colombia and Panama. I think this generation of systems is genuinely better than what came before, and I don't say that as a vendor. I say it as someone who spent more than a decade inside the older generation and does not miss it.
So this is not a hedge. It's the list I actually run through on a first call, because a project that shouldn't have started is expensive for the client and worse for me. A bad implementation doesn't just cost money; it burns a finance team's appetite for change for about three years.
Here are the seven signals that make me say not this, or not yet.
1. Your business runs on inventory
This is the clearest one, and it is the one people most often try to argue around.
Campfire, Rillet and DualEntry are finance-first systems. They are built around the general ledger, the close, revenue recognition and multi-entity consolidation. They are very good at that. None of them ships native inventory management, warehouse operations or purchasing.
If you distribute physical product, manufacture anything, or hold stock as a material part of your balance sheet, your system of record is not the ledger. It's whatever tracks the goods. The ERP has to follow the inventory system, not the other way around. Trying to make a finance-first platform the centre of an inventory business produces an architecture where the most important data in the company lives outside the most important system in the company.
What to do instead: decide first which system owns inventory. Then the finance platform integrates to it. That can still be Campfire or Rillet. Plenty of companies run a specialised inventory system with a modern ledger behind it, and it works well. But it is a two-system design, and it needs to be scoped as one from the first week. Discovering it in user acceptance testing is how projects go sideways.
2. Your invoice isn't legal until a tax authority says so
In most of Latin America, and increasingly in Europe, an invoice does not exist for tax purposes until the tax authority has validated it in advance and returned an authorisation code. Mexico's CFDI, Colombia's CUFE, Chile's DTE, Panama's CUFE, the Dominican Republic's e-CF: different names, same model. It's called a clearance regime, and it puts tax compliance inside the transaction path rather than in a report at month end.
No ERP built in the United States clears invoices on its own. That isn't a product flaw; it's a consequence of how those regimes are designed. The working architecture is the ledger plus a locally certified provider that generates the signed XML, transmits it, and returns the authorisation code, which the ERP stores against the document.
That architecture works. We've built it. But it is a real line item, it has real risk, and it is the single most underestimated part of a Latin American implementation.
When it makes this the wrong project: if you're operating in a clearance country and you don't have budget or appetite for the integration, don't start. You will end up with a beautiful ledger and an invoicing process that doesn't produce valid tax documents, which is worse than where you are now. Some countries add more. Colombia requires you to issue an electronic document on your own purchases, and a signed payroll document per employee per month. Mexico requires a second fiscal document for every payment you receive. These are not switches you turn on later.
3. Your statutory books have to be kept somebody else's way
Some jurisdictions don't just want a different report. They want a structurally different set of books.
Chile requires an annual inflation restatement of non-monetary assets and equity for tax purposes. It has no equivalent under US GAAP or IFRS, because Chile isn't a hyperinflationary economy; it's simply how the tax code works. The practical consequence is that the ERP's balance sheet will never equal the tax balance sheet, and the annual return is built from the second one. Mexico requires a chart of accounts mapped to the tax authority's own account codes and filed monthly in XML, which means the chart of accounts has to be designed for that on day one rather than adapted to it later.
What to do instead: none of this makes the project impossible. It makes it a design problem rather than a configuration problem, and it means part of the statutory work will live outside the ERP with a local accountant. Agree that explicitly at the start and say it plainly. The failure mode isn't the complexity. It's a client who discovers in month five that the system they bought to be one source of truth isn't the source their tax filings come from.
4. The system that actually runs your business is a vertical one
A travel business with IATA settlement requirements. A clinical group whose real operational system is the patient record. A construction firm whose life is in job costing at a depth no general ledger models.
In these companies, most of the operational complexity lives in a vertical platform, and that platform is not going anywhere. It gets integrated to, not migrated from. If you replace the ERP behind it, you have improved the accounting layer of a business whose hard problems are all somewhere else.
Sometimes that's still worth doing. A better ledger is a better ledger. But be honest about the size of the prize. If ninety percent of your pain is in the vertical system, an ERP project addresses ten percent of your pain at a hundred percent of the disruption.
5. Nobody has time to own the data
This is the most common real reason projects fail, and it has nothing to do with software.
Migration is largely automated now. That's genuine. The tools have got good, and moving a general ledger is no longer the months-long ordeal it was. But migration is not the same as decision-making. Somebody on your side has to decide what the chart of accounts should become, which historical periods matter and which don't, what happens to eleven years of entries that were miscoded by people who have left, and which of your forty-two expense accounts are actually the same account.
An AI can propose all of that. It cannot be accountable for it.
If your finance function is one controller who is already working late to close in fifteen days, adding an implementation is not a productivity project. It's a second job. The tooling changes how long the mechanical parts take, which is real, but the judgement parts still need a person with the authority to decide and the time to do it.
What to do instead: name that person before you sign anything, and take something off their plate. If you can't, wait a quarter. A project that starts with an owner who has capacity beats a project that starts three months earlier without one, every time.
6. Your close is slow for reasons a system can't fix
If you close in twenty days because three departments owe you information and nobody chases them, you don't have a system problem. You have an operating-rhythm problem wearing a system costume.
Automation accelerates a process that works. It does not create one. Put a fast system underneath a broken process and you get the same twenty days, plus a new tool to blame.
The test is simple and slightly uncomfortable: of the days in your close, how many are your team doing work, and how many are your team waiting for someone else? If it's mostly waiting, fix that first. It's free, and it will make the eventual implementation better. You'll be automating a process worth automating.
7. The timing is wrong
Three situations where the answer is yes, but not now.
• Mid-audit. Don't change the ledger while someone is examining it.
• Mid-raise or mid-acquisition. Diligence wants a stable set of books and a clean comparative history. Give it one.
• Too small. There is a floor. If one person keeps the books in QuickBooks and closes in four days, the return on an implementation isn't there yet. Come back when the entity count or the transaction volume has moved.
None of these are permanent. They're calendar problems, and calendar problems are the easiest kind to solve. You wait.
So when is it right?
For balance, the profile where this generation of systems is clearly the better answer:
• Multiple legal entities that have to consolidate, especially across currencies.
• A close that is mechanically heavy: reconciliations, accruals, intercompany, revenue schedules.
• A finance team being asked to support more entities or more volume without growing.
• Revenue recognition with real complexity, where a spreadsheet has become load-bearing.
• A legacy system whose cost sits mostly in maintaining it rather than using it.
If that's you, the case is strong and the implementation timelines are weeks rather than quarters. That part of the promise is true, and it's the reason I do this work.
Five questions worth asking yourself first
1. Does inventory matter to my balance sheet?
2. Do any of my entities operate where the tax authority validates invoices before they're issued?
3. Do my statutory books have to be kept in a way my management books aren't?
4. Who, by name, is going to make the data decisions, and what are we taking off their plate?
5. Of my close days, how many are work and how many are waiting?
If those answers are clean, you have a good project. If two or more give you pause, you have a scoping conversation to have before you have a software decision to make.
We'd rather tell you not to do the project than do one that shouldn't have started. If you want to test your situation against this list with someone who has no reason to sell you a licence, that's a conversation we're happy to have.
Expandia implements AI-native ERP (Campfire, Rillet and DualEntry) for finance teams operating across the Americas and Europe.