If your ERP speaks HTTP or SQL, E1pi connects to it
There is no special protocol and no plug-in to install inside the ERP. Every accounting system we have met gives out its data in one of two ways, and E1pi uses whichever the ERP already has.
The first is HTTP. SAP exposes OData services over HTTPS. QuickBooks Online, Zoho Books and Xero expose REST APIs that return JSON, with OAuth 2.0 to sign in. The second is SQL: a custom or in-house ERP usually sits on a database, and a read-only database login is all that is needed.
Because E1pi runs on a computer inside your network, it reaches an on-premise ERP's database and a cloud ERP's API the same way, from the same place. The piece of code that knows how to sign in, how to ask and what comes back is the connector. It is small, it is the thin part of the work, and it is not where the difficulty lies.
Ninety percent of the data has the same shape, because accounting does
This is the part that surprises people, and it is the real reason one product can sit on top of many ERPs. Every one of them is built on the same double-entry bookkeeping. There is a list of accounts. The accounts sit in a hierarchy of groups that decides what rolls into gross profit and what rolls into net profit. Every transaction is a set of lines whose debits equal their credits. Customer and supplier balances are made of bills that are open or settled. Stock is items with a quantity and a value.
The ERPs name these things differently, and they store them differently, but the things are the same. SAP says G/L account, QuickBooks and Zoho Books say Account. SAP says Accounting document, QuickBooks says Transaction, Zoho Books says Journal. Once you have read one ERP's trial balance you have read them all, give or take the labels. Call it 90 percent of the structure, shared.
The other ten percent is where the AI earns its keep
The amber tiles are small on the figure and large in practice. SAP stores a date as 20260930 and QuickBooks sends 2026-09-30. An Indian company's year starts in April, a Singapore company's in January, and the same group of companies has both. One ERP shows a credit balance as a negative number, another as a positive number with a debit or credit flag. GST, VAT and sales tax do not sit in the same place or carry the same fields. Which groups roll into gross profit is a decision someone made when the books were set up, and no two set-ups agree.
This is what we mean by Data Aware Integration. The E1pi model is post-trained on each ERP's data format: which data is saved where, and for a given task, which field is the right one and which only looks right. A connector tool such as Zapier or n8n stops at the connection; the model carries on into the meaning. And because E1pi is built with E1pi, when a new ERP, a new field or a new tax rule turns up, the same AI writes or updates the small connector. That is how Zoho Books arrived in weeks rather than a year, and how Xero is arriving next.
Nothing is migrated, nothing is synced and nothing is stored in between. The reports read the live books. If a voucher is corrected in the ERP at 10:04, the report opened at 10:05 shows the correction. There is no overnight job to wait for and no second copy of your data to keep honest.
One report format, any source, all companies
Put the two halves together and the result is the thing people ask about on X. The twelve fundamental reports and the Sales and Finance dashboards have one format whichever ERP is behind them. A Profit and Loss from QuickBooks and a Profit and Loss from SAP look the same, drill down the same way to the ledger and the voucher, and can sit side by side in one table for one period.
That is not a demo claim. E1pi spent two years in production inside a battery group running three different ERPs across countries: fifteen companies, three ERPs, one E1pi, one view.
Pipe HTML: the report arrives as a page, not as words
Now the second half of the question, which is the half that decides the bill. When you ask E1pi for a Profit and Loss, the AI works out which report you mean, for which period and which company, and triggers a stream. Your E1pi server reads the books live and streams the finished report to your screen as a rendered page: the tables, the percentages, the drill-downs, the charts.
The stream travels over the connection the app already holds, so the same report arrives the same way on the browser, the iPhone, the Mac or the Windows app, from the computer in your office or the VM you control. Nothing is typed into the chat word by word. The page simply appears.
Internally we call this Pipe HTML: the report is piped to the screen instead of being described in the chat. It is a small idea with large consequences, and the figure below is the whole of it.
Three things follow. The report is fast: it appears in roughly the time the books take to answer, not the minute it takes a model to type five thousand tokens. The report is exact: the 780 figures on the page are the 780 figures in the books, with no chance of one being mistyped, which a model retyping them always has. And the report is reusable: open the session next week and it is there again, read fresh from the books.
Markdown is paid for by the word, every time
Most AI products render a report by having the model type it in markdown. That is the natural thing for a chat window, and for a consumer asking for a poem it is fine. For a business it means the unit of cost is the word on the screen, and the most expensive word there is: output tokens cost five times a fresh input token and two hundred times a cached one on the Fable 5.1 list we used in our sub-agents post.
Worse, the cost does not fall with repetition. The same trial balance asked for by five people, or by one person five mornings in a row, is typed five times and billed five times. A business does not ask for a report once. It asks for the same dozen reports all month.
| Per view | Chat assistant, markdown | E1pi, Pipe HTML |
|---|---|---|
| How the report arrives | Typed into the chat, word by word5,000 output tokens, USD 0.25, after reading a 20,000-token export, USD 0.20 | Streamed to the app as a finished page |
| Time to appear | About a minute | Seconds, as long as the books take to answer |
| The figures | Retyped by the model | Copied from the books |
| Opened again | Typed again, billed again | There again, no new bill |
| Model cost per view | USD 0.45 | about USD 0.01 |
We think this is one of the quiet reasons AI adoption inside businesses lags behind the demos. The unit of pricing, the token, does not match the unit of business value, which is the report, the voucher, the approval. A meter that runs faster the more your team uses the tool is a meter nobody wants to switch on for twenty people.