Why ERP Cannot Solve SMB Procurement (Even Modern, AI-Native ERP)

Abstract

The most persistent misreading of the SMB procurement gap is that the only thing wrong with ERP at the small-business tier is the price tag. Make it cheaper, make it AI-native, ship it on a modern stack, and the gap dissolves. This essay argues the opposite. The barrier to ERP at SMB scale has never been price. It is complexity, ongoing maintenance, setup effort, and the cost of keeping a configurable system in shape — costs that are invariant to whether the ERP is built in 1998 or 2026, in COBOL or React, with rule engines or large language models. The SMB answer is not a smaller, prettier, or AI-fier ERP. It is a different shape of system entirely — one that infers, reconciles, and executes across the tools the operator already runs, instead of asking them to model their business in a custom schema first. We lay out the four failure modes of the database-first architecture, why "modern AI-native ERP" repeats them in nicer clothes, and what the workflow-first SMB-native alternative looks like.

I. The misdiagnosis

Walk through the last twenty years of SMB-aimed ERP attempts and one pattern is constant: the people building them believe the problem is that ERP is too expensive and too ugly. So they build a cheaper, better-looking ERP. They lower the entry price, they redesign the screens, they add AI on top, and they re-launch into the same gap. Then the same thing happens. The SMB operator opens the demo, closes the tab in eight minutes, and goes back to the spreadsheet.

This pattern has now repeated through several technology cycles. In the 2000s it was on-premise ERPs porting to the cloud. In the 2010s it was browser-native ERPs replacing desktop ones. In the 2020s it is AI-native ERPs replacing rule-based ones. The entry price has come down by an order of magnitude across these cycles. The SMB adoption rate of ERP has not meaningfully moved.

This should be a clue. If price were the binding constraint, the curve would have responded by now. It hasn't. The constraint is somewhere else.

We say so because we built LineNow with a particular thesis about where the constraint actually is, and because we keep meeting product managers from ERP companies who believe — with real conviction — that the next price drop or the next AI feature is the one that will finally crack the segment. It will not. The problem is not in the price line of the ERP. It is in the architecture of the ERP.

II. The actual barriers

Five things stop SMBs from running an ERP. Price is at most one of them, and not the largest one.

Configuration burden. Every ERP, modern or otherwise, asks the operator to model their business before the system does useful work. Items, units of measure, suppliers, customers, locations, departments, accounts, workflows, approval chains, fields, permissions, integrations. This is the master data step. It exists because an ERP is a configurable database, and a configurable database has to be configured. The configuration step takes weeks of work the operator does not have time for, by someone with operational instincts the operator usually doesn't have on payroll.

Ongoing maintenance. Configured systems decay. The product mix changes; new suppliers appear; tax rules update; integrations break; reports stop being right. Someone has to keep the ERP in shape. In a 200-person company that someone is a systems analyst on the IT team. In a 12-person café it is the owner, and so it is no one. The maintenance cost is invisible until it isn't, at which point the ERP has rotted into a database the operator avoids opening.

Hiring. Real ERP deployments require humans whose entire job is the ERP — implementation specialists, ops analysts, controllers, internal SMEs. The salary line for "the person who keeps NetSuite working" is between $80,000 and $200,000 depending on geography. SMBs do not have that salary line. They cannot create one without breaking their own unit economics. So they don't, and the ERP underperforms relative to its sticker, and they conclude — correctly — that the system is not for them.

Setup time. A typical ERP deployment takes six to nine months end-to-end, even at the friendly end of the market. Modern AI-native ERPs claim to compress this to weeks. Sometimes they do. Weeks is still a horizon the SMB operator does not have. They are trying to send a PO tonight. They want to be generating buy recommendations by Friday. The unit of time the SMB operates in is the day, occasionally the week. The ERP unit of time is the quarter. These are categorically different scales.

Cognitive surface area. The deepest barrier and the one nobody talks about. ERP is built for the operating model of a company that has separated procurement, finance, inventory, fulfillment, and sales into different functions, with different people in different roles, exchanging documents between modules. The SMB operator is one person performing all of those functions. They do not have the cognitive bandwidth to navigate a system designed around the assumption that they are five people, even if the system is well designed inside that assumption. The interface metaphors of ERP — modules, journals, line types, GL codes, dimensions — are concepts the SMB operator never had to think about and does not want to start now.

Sticker price is item six on this list, at best.

III. Why the database-first architecture cannot be SMB-friendly

ERPs are built on a particular architectural pattern that we will call database-first. The pattern is straightforward. The system is a relational database with a schema describing the operating universe of the business. Master data goes into the schema. Transactions are state changes against that schema. Reports are queries on the schema. Workflows are sequences of state changes wired by a rule engine or a configuration layer.

This pattern is internally consistent and powerful. It is also wrong for SMBs, and not for any reason that a price drop can fix.

The problem is that the database-first pattern requires the schema to be filled in before the system does any work. You cannot run replenishment math on items that haven't been entered. You cannot post a journal entry to an account that doesn't exist. You cannot send a PO to a supplier whose record is empty. The data is the precondition for the workflow. So the operator's first job, every time, is to be a data entry clerk for their own business. Until that work is done, the ERP does not pay back the time invested in it. For most SMBs, the work is never done — because the business keeps changing, and master data has the property that it is always slightly stale.

A modern AI-native ERP relaxes this in places. AI can extract a supplier from a PDF, suggest a category for a new item, propose an account code. Useful at the margin. None of it changes the architectural fact. The schema still has to be modeled. The configuration still has to be made coherent. The workflows still have to be wired. AI on a database-first architecture is a faster way to fill in a schema. It is not a way to operate without one.

The deeper consequence is that the database-first pattern hardcodes an inversion of where decisions live. In an ERP, the schema is the system's view of the business, and the operator is responsible for making the schema correct. The system serves the schema. The schema does not serve the operator. When reality and schema diverge — and they always diverge — the operator is on the hook to reconcile them. This is the source of the rot. Every ERP we have ever met that an SMB tried to use was, three months in, a database the operator no longer trusted.

IV. Why "modern AI-native ERP" repeats the same failure

Several startups in the last cycle have attempted what we will charitably call the modern ERP — a redesign of the configurable system-of-record category for product brands. Doss is the cleanest current example; there are others, in spirit if not in form, on YC batches and on Series A decks across the industry. They share a few claims:

1. We are AI-native, and AI eliminates the configuration burden.
2. We are flexible, and flexibility is what SMBs actually need.
3. We are modern, and modern means fast to deploy.
4. We are a real system of record, unlike the toys (Shopify apps, spreadsheets, etc.) that SMBs use today.

Each of these claims is partially true at the upper end of SMB and into mid-market. Each of them is wrong at the SMB owner-operator tier where the gap actually lives.

On AI eliminating configuration. AI can help fill in a schema. It cannot decide that the schema should not exist. The AI on a configurable ERP is, structurally, a productivity tool for the systems analyst. The SMB operator is not the systems analyst. They are not trying to fill the schema in faster; they are trying not to have to fill it in at all.

On flexibility being the answer. Flexibility is a feature for buyers who have ops teams capable of using it. For an SMB owner-operator, flexibility is a tax. Every flexible field is a field they have to decide what to put in. Every configurable workflow is a workflow they have to design. The SMB win condition is the of flexibility. It is opinionatedness — a system that has decided how purchasing works, and that you teach to the assistant once.

On modern meaning fast to deploy. Modern frameworks are faster to develop on, not faster to deploy a configured system on. The bottleneck has never been the implementation team's compile time. It has been the operator's ability to model their own business under time pressure while still running the business. That bottleneck is invariant to the framework.

On being a real system of record. This is the framing that gives the strategy away. The implicit claim is that what SMBs use today is illegitimate — a Shopify, a Square, a QuickBooks, a stack of supplier emails — and the legitimate answer is to consolidate those systems into one configurable database. We disagree, and the disagreement is structural. Shopify, Square, Toast, Faire, Clover, QuickBooks, and the supplier email thread are the system of record at the SMB tier. They are real, they are battle-tested, they are running 33 million businesses in North America. The job of an SMB-native procurement system is not to replace them. It is to operate across them — to read what is already true in those systems and execute the procurement workflow on top.

The modern ERP bet is, fundamentally, the bet that the SMB segment is currently using the wrong systems and should be moved onto the right ones. The SMB-native bet is that the SMB segment is using the right systems and is missing the workflow that runs across them. These are not the same bet. They are not refinements of each other. They are different theses about what is broken.

V. The SMB-native alternative: infer, reconcile, execute

If the database-first pattern is wrong for SMBs, what is the alternative? A different architectural primitive, which we will call workflow-first. The pattern looks like this.

Instead of asking the operator to model the business into a schema, the system observes the business through the tools the operator already uses, and infers the operating data as a byproduct of those tools running. POS sells a unit; consumption goes up. Supplier replies to an email; the order state changes. A bill arrives; the receivable closes. The data plane is not master data the operator types; it is the residue of the business actually running in its existing systems.

Three primitives carry the load.

Infer. Read POS for sales and consumption. Read the supplier inbox for replies, prices, ETAs, substitutions, MOQs, lead times. Read the receiving record for what actually arrived. Read QuickBooks for what was paid. Build the operating picture from these signals, not from a configuration form. The operator does not maintain a supplier table; the system infers the supplier table from the emails the supplier sent.

Reconcile. When signals disagree — the PO said 10 cases, the email said 8, the receipt said 7 — the system reconciles automatically against the most recent ground truth and surfaces the diff to the operator. The reconciliation is the system's job. The operator is not the human glue between five tools.

Execute. When a decision is made — send this PO, approve this substitution, post this bill — the system executes through whichever channel each counterparty actually uses (email, WhatsApp, EDI, supplier portal, QuickBooks). It does not require the supplier to log in, the operator to retype, or anything in between.

These three primitives compose into a closed loop: the loop runs autonomously, the operator presses a small number of buttons, and the master data is a side effect. There is no schema modeling step because there is no schema the operator has to fill in. There is no configuration burden because there is nothing to configure — the defaults are derived from the operator's actual data. There is no maintenance cost because the system is not maintained against a schema; it is maintained against reality.

This is what we mean by SMB-native. It is not a lighter ERP. It is a fundamentally different system that occupies the part of the operating universe where ERPs cannot reach.

VI. The teachable-to-the-assistant test

Here is the test we use internally to decide whether a feature belongs in LineNow.

A reasonable proxy for an SMB operator is a small business owner named Jill, who runs a 12-seat café, and her assistant Shannon, who started six months ago and has never seen an ERP. The test is: can Jill teach Shannon this feature in one minute, and trust Shannon to use it correctly on Tuesday morning while Jill is at the doctor?

If yes, the feature passes. If no — if the feature requires Shannon to understand a configuration page, a settings panel, a custom field, a rule engine, a workflow editor, or a concept that is not native to the workflow itself — the feature fails. We do not ship it. We rebuild it until it passes, or we cut it.

This test has a remarkable filtering effect. Almost everything an ERP considers a feature fails this test. Multi-level approval workflows fail. Custom dimensions fail. Configurable valuation methods (FIFO/LIFO/weighted-average pickers) fail. Rule engines fail. Permission matrices fail. Custom fields fail. Most "modern ERP" AI features fail too, because they require Shannon to understand a configurable schema before she can use them.

Almost everything in the closed-loop procurement workflow passes. "Click send to email this PO to your supplier" passes. "Approve the substitution your supplier proposed" passes. "This is what the system thinks you should order this week — review and send" passes.

This is not a UX test, although it looks like one. It is an architectural test. Features that pass it are features that fit a workflow-first system. Features that fail it are features that fit a database-first system. The two architectures filter different feature sets, and the filter is sharp. There are very few features that pass on a database-first system and very few features that fail on a workflow-first one.

VII. Why the SMB-native bet was not viable until now

The alternative we describe — observe the existing tools, infer the data, reconcile state, execute through native channels — was not technically possible until recently. Three constraints relaxed in the last few years and made it viable for the first time.

POS as the consumption oracle. Square, Shopify, Toast, Clover, and Lightspeed now collectively cover the majority of SMB transactions in North America. All five expose item-level sales through APIs. For the first time, the consumption signal is available at the SMB tier in machine-readable form, in real time. Without this, no procurement system can recommend what to order; the operator has to. With it, the system can.

Language models that read unstructured supplier reality. Procurement runs on unstructured communication — emails, PDFs, scanned invoices, WhatsApp messages, phone-call followups. Until recently, parsing these required either humans or fragile regex. Frontier language models have now crossed the threshold where structured extraction from supplier communication can be productized with confidence scoring, review queues, and audit trails. Without this, the loop cannot close on the supplier-reply step. With it, the system reads the reply, updates the PO, the inventory, the bill match — and the operator does far less manual reconciliation.

Bidirectional supplier graphs. Every previous wave of procurement software treated the supplier as an externality. The next wave runs both sides on the same database — the buyer's procurement system is, simultaneously, the supplier's order management system. As the platform reaches density, the AI parsing step becomes redundant for an increasing share of transactions because the data is already structured at source. The flywheel is identical to the one that built Stripe and Shopify.

These three relaxations are why the SMB-native bet is possible now and was not possible in 2015 or 2008. They are also why the modern ERP bet is mistimed: at exactly the moment that the SMB-native architecture becomes available, a wave of startups is putting AI on the database-first architecture instead. The AI is real. The architecture choice is wrong. The combination produces a more polished version of a system the SMB operator was already not going to use.

VIII. The economic consequence

If the analysis is right, the economic consequence is large. The SMB segment contains roughly 33 million businesses in the United States and 1.2 million in Canada. Conservatively, 35% have meaningful procurement — call it 12 million businesses. The price point of a viable SMB-native procurement system is in the $50–$200/month range, the price point at which the operator can self-serve onto the platform without an implementation budget.

At a blended ACV of $1,000/year across that segment, the procurement layer alone is a $12 billion ARR ceiling in North America. The supplier-side flywheel — embedded payments, supplier financing, freight booking, predictive cash — multiplies the ceiling several times. The total addressable enterprise value is in the $50–$200 billion range.

That is the prize for getting the SMB-native architecture right. The reason no incumbent has captured it is that the incumbents are running the database-first playbook, which is structurally incapable of crossing into the SMB segment regardless of how cheap or how AI-assisted it becomes. The reason no modern ERP has captured it is that they have made the same architectural choice in nicer wrapping. The architecture is the gate. Pricing is downstream.

IX. The seven principles that follow

If you take the analysis seriously, an opinionated set of design principles falls out. We have written them down before in The LineNow Manifesto; we restate them here in the specific frame of "what an SMB-native procurement system has to do that an ERP cannot."

1. The system knows what to order. No PAR-level forms to fill out. The minute POS connects, statistical replenishment math runs against real consumption. The operator stops guessing.
2. AI reads the supplier reply. Email, WhatsApp, EDI, web portal — the system reads, parses, updates the PO and the bill. The operator types nothing.
3. Suppliers stay where they are. No portal to drag them onto. No app to install. The system absorbs the variance.
4. There are no settings. The defaults are derived from the operator's actual data. The opinions are right more often than the operator's would be, because the system has more data.
5. Money and goods reconcile in one place. PO becomes invoice becomes payment becomes receipt becomes COGS entry. One object, one audit trail, no journal-entry reconciliation at midnight.
6. The supplier matters. The supplier-side and buyer-side run on the same database. Every supplier added makes the platform more valuable to every buyer.
7. The operator presses the button. AI does not auto-purchase. The system proposes; the operator decides. Accountability stays with the human.

Every one of these principles is incompatible with the database-first architecture. None of them are configurable settings on a modern ERP. Each of them is a structural property of a workflow-first system or it is not present at all.

X. The closing argument

The SMB procurement gap is not solved by pricing an ERP lower. It is an architectural mismatch between the database-first pattern and the operating reality of small businesses. The mismatch survives every refinement of the database-first pattern — cloud delivery, modern frameworks, AI assistance, configurable schemas — because the mismatch is at the architectural layer, not at the implementation layer.

The companies that will close the SMB procurement gap will not look like ERPs at all. They will look like workflows. They will read POS, parse supplier email, infer master data, reconcile state automatically, execute through native channels, and present a small number of decisions to a single human who presses a small number of buttons. The database underneath them will be a side effect of the workflow, not a precondition for it. They will be priced at SMB-affordable monthly subscriptions because they require no implementation budget. They will be self-serve because they require no configuration. They will be trusted by Shannon on Tuesday morning because they were teachable in a minute.

This is not a small claim. We are saying that the entire category of ERP — including the modern, AI-native, beautiful-looking versions currently raising at strong valuations — is the wrong shape for the largest segment of the market it is being aimed at. We are saying that the segment will not be won by competing on ERP terms; it will be won by departing from them. We are saying that the operator who is reading this essay on a Tuesday night, with a procurement spreadsheet open in another tab, is not going to have their problem solved by a smaller NetSuite or a prettier NetSuite or an AI-fier NetSuite. They are going to have their problem solved by a system that does the procurement loop itself, end to end, without asking them to be a systems analyst.

That is the system we are building. It is not what an ERP is. It is what comes after.

The product behind the thesis

LineNow is the closed-loop procurement platform built on the principles set out in this essay — workflow-first, no configuration, observation-and-inference data plane, native multi-channel supplier comms, two layers of AI inside the loop, and team collaboration on the supplier email thread itself. Multi-vertical (retail + dropship + restaurant + manufacturer) in one account. Statistical replenishment with decay-aware safety stock. Recipe / BOM costing. Bills push to QuickBooks / Xero. Embedded payments. $50/month flat, 90-day free trial.

For the SMB operator who has read this essay and recognized their own business in it, LineNow is the answer. There is no ERP, modern or otherwise, that runs the closed loop with this depth at this segment.

Related

• Procurement After Spreadsheets: A Thesis on the Future of Small Business Operations — long-form thesis on the category
• The LineNow Manifesto: Stop Buying Like It's 2005 — short polemical version
• What LineNow Replaces vs Enhances — honest accounting of where LineNow sits in the SMB stack
• The Procurement ROI Math — what closing the loop saves in dollars and hours
• Closed-loop procurement, in plain English
• How AI Reads Your Supplier Emails — the architectural capability that closes the loop
• LineNow vs Doss — the workflow-first vs database-first comparison made concrete
• LineNow vs Cin7 · vs Precoro · vs Procurify