Daniel's been wrestling with a hole in his mental model — the whole ERP world, top to bottom. He's never worked anywhere that ran one, so the category's something he's only ever watched from the outside. At the top, SAP: a titan that runs the back office of a huge chunk of the world's large enterprises, and yet a brand that never became a cultural object the way Salesforce did. Salesforce gave the industry a tower, a conference, a vocabulary — a whole aesthetic. SAP just quietly ran everything and stayed boring. So part one of his question is the history: how SAP got that dominant, and what makes it so hard to dislodge. But the part he really can't picture is the bottom. Take a wine shop, one or two staff. There's inventory, sales, tax record-keeping. Nobody's standing up SAP. What they've got is a terminal on the counter — here in Israel that's often HYP, the payments processor sister to Max, which sells registers and digital invoicing and pitches the bundle as managing your business. Square and Shopify POS run the same play elsewhere. So where's the join? Is the counter terminal a shallow ERP, or a fundamentally different thing — and what forces a growing business to cross from one to the other? And then the sharpener: the ERP incumbent in Israel isn't SAP at all, it's Priority Software out of Rosh Ha'ayin, holding well over double SAP's local share. Whatever explains that probably explains the whole gap. So we're going to start at the top, with the titan that never became a celebrity.
The thing to understand about SAP's dominance is that it's not a story about software being better. It's a story about timing and architecture. In the nineteen seventies, when SAP was founded by five ex-IBM engineers in Germany, the standard way large companies ran their back offices was batch processing. You'd collect all the day's transactions, feed them in overnight, and get reports in the morning. SAP's insight — and this was genuinely ahead of its time — was real-time integration. Enter a sales order, and inventory updates immediately. The general ledger sees it. Production planning sees it. Everything talks to everything else, instantly.
So the structural advantage wasn't features. It was that batch processing meant the business was always a day behind itself.
And for a multinational with thousands of transactions an hour, that lag was lethal. By the time the batch report told you a warehouse was empty, you'd already sold another three days of stock you didn't have. SAP's real-time architecture solved that. And they built it in the era when mainframes were the only game in town for companies of that scale. By the time client-server and then the web arrived, SAP was already embedded in the Fortune 500. They weren't the only ones — Oracle was right there too — but SAP owned the integrated suite story. Finance, HR, procurement, manufacturing, all in one system, all talking in real time.
And once it's in, it's in.
That's the lock-in, and it's the part most outside observers get wrong. People assume the switching cost is the license fees. It's not. The switching cost is that over ten or fifteen years, SAP has become the organization's data model. Every custom field, every workflow, every report — thousands of them — were built by people who may not even work there anymore. The institutional knowledge of how the business actually runs is encoded in the SAP implementation. Rip it out, and you're not just installing new software. You're re-learning how your own company works, from scratch, while it's still operating.
So it's less like replacing a tool and more like replacing the nervous system.
And the nervous system analogy holds in another way: nobody thinks about it until it stops working. SAP runs payroll for something like fifty million people globally. It processes an enormous percentage of the world's business-to-business transactions. It's invisible infrastructure, the way the electrical grid is invisible — until the lights go out, you don't know it's there.
Which gets us to the second part of Daniel's question. Salesforce built a skyscraper in San Francisco, runs Dreamforce as this massive gathering, gave people the word "Ohana" — it became a lifestyle brand for people who live in spreadsheets. SAP never did any of that. Why not?
It's not an accident of marketing. It's who they sell to. Salesforce sells to the sales VP, the marketing director, the customer service head — people whose job is external, visible, and frankly, status-driven. Showing up at Dreamforce and wearing the trailblazer hoodie is part of the identity. SAP sells to the CFO and the IT department. The CFO does not want a hoodie. The CFO wants the books to close on time and the audit to go cleanly. There's no conference that makes a controller feel like part of a movement, because the controller doesn't want a movement. They want the system to work and to never have to think about it again.
The front office colonized the imagination. The back office colonized the general ledger.
And never needed the imagination. That's the whole thing. SAP's brand is boring because boring is the product. If your ERP is exciting, something has gone terribly wrong.
Alright, so that's the top of the market. Now let's zoom all the way down to the counter of a wine shop.
This is where the mental model gets interesting. When you walk into a small wine shop in Tel Aviv or wherever, and they ring you up on a HYP terminal — or Square, or Shopify POS — it's tempting to look at that and think, well, it's tracking inventory, it's recording sales, it's handling tax. That's what SAP does, just smaller. A shallow ERP.
And you're about to tell me that's wrong.
It's wrong in a way that matters. The counter terminal is a payments-first system. Its job is to complete a transaction and record it. Everything else — the inventory tracking, the invoicing, the customer list — is bolted on as a convenience. The terminal's source of truth is cash. Did money move? Yes. Here's the record.
Whereas SAP's source of truth is... the business itself?
The business model. An ERP is a model of the business. It answers questions the terminal never even asks. How much stock should we order for next quarter? If we open a second location, what's the consolidated margin? If the supplier raises prices by three percent, what happens to our cash flow in six months? The terminal records what happened. The ERP plans what should happen next.
One is a ledger. The other is a planning system.
And they only look adjacent from the outside. From the inside, they're answering fundamentally different questions. The wine shop owner at the end of the day needs to know what was sold and how much tax is owed. The terminal does that perfectly. The moment that owner opens a second shop and a warehouse, the questions change. Now they need purchase orders. They need to forecast demand across locations. They need consolidated financials. The terminal's record-keeping can't answer "what should we do next?" — it can only answer "what did we do?"
So the join isn't volume of sales. It's the moment you need planning.
Right. You can do ten million dollars a year through a single location with a terminal and an accountant, and plenty of businesses do. The trigger for ERP isn't revenue — it's complexity. Multi-location inventory. Procurement that needs approval workflows. Financial consolidation across entities. The second you have a warehouse that supplies two stores, you need to know not just what sold, but what to order, when to order it, how much shelf space to allocate, and what the margin looks like after inter-store transfers. That's when the terminal stops being enough.
So if the terminal is a ledger and SAP is a planning system, where do they actually meet?
They don't, really. What happens is the business outgrows the terminal and jumps. One day the owner is running the shop and the terminal is fine. The next day — and it often feels this sudden — they're spending hours in spreadsheets trying to figure out stock levels across locations, and someone says "we need a system." That system is an ERP. Not SAP — nobody jumps from a HYP terminal to SAP, that would be insane — but something in the mid-market.
And that's where the Israel story gets interesting. Because the incumbent there isn't SAP at all.
Priority Software. Out of Rosh Ha'ayin. By most estimates they hold more than double SAP's local market share in Israel. And the reason is exactly what we've been describing — it's the mid-market gap.
Walk me through that.
SAP is built for the global enterprise. The implementation costs are enormous, the customization requires specialized consultants, and the whole thing assumes you're operating across multiple countries with complex regulatory requirements. Most Israeli companies aren't that. They're mid-market — fifty to five hundred employees, operating primarily in Israel, with Hebrew-language needs and local tax and regulatory compliance that a global system treats as an afterthought.
So Priority built for that scale.
Hebrew-language support from day one. Local tax compliance — VAT, withholding, all the Israeli-specific reporting requirements — baked in, not bolted on. A services and support model that fits the local business culture. And pricing and implementation complexity that matches the mid-market, not the Fortune 500. The same logic that explains why the wine shop doesn't run SAP explains why the Israeli mid-market doesn't either. It's not that SAP is bad. It's that SAP is the wrong tool for the job.
The market is tiered by business complexity, not by size alone.
And that's the thing Daniel's question is really getting at. The ERP market isn't a single spectrum from small to large. It's a set of distinct tiers, and the boundaries between them aren't about how much money you make — they're about what kind of questions you need your systems to answer. The terminal answers "what happened." The mid-market ERP answers "what should we do next week." The enterprise ERP answers "what's our consolidated position across seventeen countries under three different regulatory regimes."
HYP and Square and Shopify are interesting here because they're trying to blur that first boundary. HYP now pitches the whole bundle as "managing your business" — not just payments, but registers, digital invoicing, some inventory tools. They're creeping upward.
They are, and it's smart. If you're already the payment processor, you see every transaction. Adding a layer of "business management" on top of that data stream is a natural extension. But there's a ceiling. The moment the business needs purchase order workflows, or multi-location inventory forecasting, or any kind of planning function, the payments-first architecture hits a wall. You can't bolt planning onto a ledger without fundamentally rebuilding the data model.
It's the difference between a checkbook register and a financial model. You can add categories and notes to the checkbook register all day — it's still not going to tell you your cash flow projection for Q3.
And that's the ceiling. Square and Shopify know this — they're not trying to compete with mid-market ERPs. They're trying to capture the layer just below, the businesses that are too complex for a dumb cash register but not complex enough to need a real planning system. It's a real market, and it's growing.
Let me pull on something Daniel mentioned about SAP's cultural invisibility. You said it's because they sell to the CFO. But there's another dimension here — the developer ecosystem. Salesforce built a platform. You can build a career as a Salesforce developer. There are certifications, a job market, a whole identity. SAP has ABAP developers, but nobody outside the SAP world knows what ABAP is.
And nobody wants to. ABAP is not a language you learn because you're curious about programming. It's a language you learn because your employer runs SAP and someone needs to customize the procurement module. There's no ABAP meetup where people show up in t-shirts and get excited about the latest release. It's a tool for a job, not a community.
Whereas Salesforce made "trailblazer" a thing people put in their Twitter bio.
Unironically. And that's not a dig at Salesforce — they built something real. But it's a front-office phenomenon. The back office doesn't generate that kind of identity because the work is invisible by design. Nobody brags about the general ledger closing smoothly.
Alright, I want to go back to the lock-in mechanism for a minute, because I think there's a dimension we haven't touched. It's not just the data model and the customizations and the trained staff. It's also the regulatory compliance.
Say more.
SAP has spent decades building compliance for every tax regime, every financial reporting standard, every industry-specific regulation across something like a hundred and ninety countries. If you're a multinational, that's not a feature you can replicate by switching to something else. You'd have to rebuild all of it. The compliance alone is a moat.
It's a massive moat. And it compounds. Every time a country changes its tax code, SAP updates the system. Every time a new reporting standard comes out, it's handled. Over thirty or forty years, that accumulated compliance knowledge is arguably more valuable than the software itself. A competitor can build a better user interface. They can't replicate forty years of regulatory edge cases across two hundred jurisdictions in eighteen months.
Which means the lock-in gets stronger over time, not weaker. The cloud was supposed to lower the barrier to entry for ERP competitors. And it has, at the mid-market level. But at the enterprise level, the compliance moat is deeper than ever.
And that's the tiering again. The cloud absolutely changed the game for the mid-market. Priority Software, NetSuite, Acumatica — these are cloud-native or cloud-available ERPs that don't require the massive on-premise infrastructure SAP traditionally demanded. They lowered the implementation cost and the ongoing maintenance burden. But they're not competing for the Fortune 50. They're competing for the mid-market, where the compliance requirements are simpler and the multi-country complexity is lower.
So the cloud didn't flatten the market. It just made the mid-market tier more accessible.
Which is exactly why Priority could win in Israel. They didn't need to beat SAP at the global enterprise game. They needed to be the best option for Israeli companies at the Israeli scale, with Israeli compliance, in Hebrew. And they are.
Let's talk about HYP specifically for a moment, because I think it illustrates something about the payments-first architecture. HYP is a payments processor — it's the sister company to Max, the credit card company. The terminal on the counter is, first and foremost, a way to process credit card payments. The register, the invoicing, the "manage your business" pitch — those are additions built on top of the payment rails.
And that's the same play Square ran. The card reader was the wedge. Once you're processing payments through Square, adding inventory tracking and invoicing and customer management is a natural upsell. The payments data is already flowing through the system. You might as well surface it.
But the architecture flows from the payment, not from the business model. The data model starts with the transaction. Everything else is derived.
Yes. And that's the ceiling we talked about. An ERP starts with the business model — the chart of accounts, the organizational structure, the supply chain — and the transactions flow from that. It's the opposite direction. The terminal says "here's what happened, let me help you organize it." The ERP says "here's how the business is structured, let me help you plan what happens next."
So when HYP pitches "managing your business," they're really saying "we'll give you a nicer view of your transaction history."
Which is useful for a lot of businesses. Most small shops don't need more than that. The danger is when a growing business mistakes that transaction view for actual planning capability. You can look at a dashboard of last month's sales and feel like you're managing the business. You're not. You're reviewing the past. Planning requires a different kind of system.
The wine shop with one location: the terminal is perfect. The wine chain with a warehouse and three stores: the terminal is a receipt printer that happens to have a screen.
And the moment in between — that's where the pain lives. The owner is running the chain but still using the terminal, and suddenly they're in spreadsheet hell, trying to figure out why one store is out of the cabernet while the warehouse has twelve cases that nobody knew about. That's the crossing point. Not a clean transition. A mess that forces the jump.
Let me ask you something about the Israeli market specifically. Priority's dominance — is it purely the mid-market fit and the Hebrew support, or is there a cultural dimension too?
There's absolutely a cultural dimension. Israeli business culture is... let's call it high-context. Relationships matter. The support model matters. If something breaks at two in the afternoon on a Thursday, you want to call someone who picks up and speaks Hebrew and understands that the weekend starts Friday morning. Priority built that. SAP's support model is global, ticketed, and operates at a scale where you're one of thousands of customers in a queue. For an Israeli mid-market company, that's not acceptable.
It's not just the software. It's the whole services model.
The sales motion. Priority sells to Israeli business owners in a way that fits the local market. SAP sells to global procurement departments. Those are different conversations, different expectations, different relationships. The software is only part of the product.
Which circles back to something Daniel was getting at. The ERP market looks like a single category from the outside — "software that runs the business." But once you're inside, it's three or four different markets wearing the same name.
At minimum. You've got the payment-terminal layer — HYP, Square, Shopify POS. You've got the small-business accounting layer — QuickBooks, Xero. You've got the mid-market ERP layer — Priority, NetSuite, Acumatica. And you've got the enterprise layer — SAP, Oracle. They overlap at the edges, but they're solving different problems for different buyers with different expectations. The fact that they all touch "inventory and sales" is like saying a bicycle and a cargo ship are both transportation.
Alright, I want to name the misconception that sits at the center of all this. The counter terminal is not a shallow ERP. It's a fundamentally different thing. Calling it a shallow ERP is like calling a diary a shallow novel — it's not a less sophisticated version of the same category, it's a different category entirely.
The diary records what happened. The novel has a structure, a plot, a design. The ERP has a structure. The terminal has a record. Different tools, different questions.
Which means the market isn't a ladder you climb rung by rung. It's a series of distinct platforms, and you jump from one to the next when the questions you need to answer change.
Most businesses never need to jump. The vast majority of companies in any economy are small enough that a terminal and an accountant are perfectly sufficient. The ERP market looks enormous from the inside because the companies that need it are enormous. But the number of businesses that actually need a planning system is a tiny fraction of all businesses.
Daniel's wine shop probably never needs an ERP. The moment it becomes a chain, it does. That's the whole story.
Hilbert: Used to run a bookshop.
...Sorry?
Hilbert: Early nineties. Little place in Haifa. Had a register. DOS-based. Green screen. Tracked inventory, sales, tax — the whole thing. That register was an ERP.
Hilbert, I have so many questions. What was the system?
Hilbert: Custom thing. Guy named Moti built it. Ran off a floppy disk. You typed in the ISBN and it told you if we had it, what we paid, what the margin was. End of the day it printed a tax report. That's an ERP.
Did it do purchase orders?
Hilbert: I knew what to order because I looked at the shelf.
Right, so the planning was in your head, not in the system.
Hilbert: The system told me what sold. I did the planning. Same thing, just... distributed.
That's not the same thing. That's a ledger plus a human planner. The ERP is supposed to be the planner.
Hilbert: The shoebox was the planning system.
The shoebox.
Hilbert: Receipts, notes, supplier catalogs. Everything Moti's system didn't do, the shoebox did. Between the green screen and the shoebox, I had full ERP coverage.
You're describing a ledger and a filing system and calling it an ERP.
Hilbert: I'm describing what worked. Ran that shop for six years. Never lost a shekel.
You never lost a shekel because you were the ERP. The system just remembered what you told it.
Hilbert: That's all any of them do. SAP's just a bigger shoebox.
I... there's a difference in kind between a shoebox of receipts and a multi-entity financial consolidation engine.
Hilbert: Scale, not kind. A register is an ERP for one person. SAP is a register for a thousand people. Moti understood this.
Moti's green-screen register didn't do forecasting, procurement workflows, or consolidated financials across entities. It recorded transactions and printed a tax report. That's the point we've been making.
Hilbert: Forecasting was me looking at the shelf. The system didn't need to do it.
Which means the system wasn't doing it. You were.
Hilbert: I was part of the system. That's what people forget. The human is in the loop either way. SAP just pretends it's not.
I don't think SAP pretends the human isn't in the loop. I think it automates the parts that can be automated so the human can do something more useful than counting books.
Hilbert: Counting books is useful. You learn things counting books that a dashboard won't tell you.
What kind of things?
Hilbert: Which ones people pick up and put back. Which covers are fading near the window. Whether the new Grisham is moving or just being looked at. Inventory count tells you what's there. Shelf time tells you what's happening.
...That's actually a good point.
Hilbert: Moti's system didn't track that either. But I did. The shoebox had notes.
Hilbert, I want to know — do you still have the shoebox?
Hilbert: Somewhere. Moved three times since then. But I know which box it's in.
Of course you do.
The thing about what Hilbert's describing — and I think he's half right even if he's completely wrong about the definition — is that the small business owner is the integration layer. The terminal handles payments. The shoebox handles planning. The owner's brain connects them. An ERP automates the connection. That's the difference. It's not that the small shop doesn't plan. It's that the planning lives in the owner's head and a shoebox, not in software.
The crossing point is when the owner's head and the shoebox can't keep up anymore. When there are too many shelves, too many locations, too many suppliers for one person to hold the model.
Hilbert: That's fair.
The misconception I'd leave people with is exactly what we've been saying. The counter terminal is not a shallow ERP. It's a ledger. It records transactions. An ERP is a planning system — it models the business and answers "what should we do next?" They look similar from the outside because they both touch inventory and sales, but they're answering fundamentally different questions. And the market isn't a single ladder from small to large — it's tiered by business complexity, and you jump from one tier to the next when the questions change.
The wine shop's terminal and SAP are both managing the business. But one answers "what happened?" and the other answers "what's next?" That's the gap Daniel was asking about — and it's not a gap you close by adding features to the terminal. It's a gap you cross by changing the kind of system you use.
The open question — and this is where I think the next few years get interesting — is whether the cloud and AI start eating that gap from both sides. If HYP and Square keep adding "business management" features, and mid-market ERPs keep getting easier to deploy, do they eventually meet in the middle? Or does the planning-versus-ledger distinction hold because it's architectural, not just a matter of features?
My bet is the distinction holds. You can add all the dashboards you want to a payments-first system, but if the data model starts with the transaction rather than the business structure, you hit a ceiling. Planning requires a model. Ledgers don't have one. That's not a feature gap — it's a category difference.
On that note — thanks to our producer Hilbert Flumingtop, who apparently ran a bookshop and kept a shoebox that he still knows the location of.
We're going to need to see that shoebox someday.
This has been My Weird Prompts. Find us at my weird prompts dot com, and if you've got a mental model with a hole in it, send it our way — show at my weird prompts dot com. We'll be back soon.
