The operational backbone for mid-market and enterprise.
Financials, procurement, manufacturing, sales, inventory and reporting — on one runtime, with one metadata repository, sharing one security perimeter. Real-time across modules; no integration tax, no reconciliation cycle, no spreadsheet bridges. Every line of the system owned by the customer.
One data model
Finance, sales, procurement, inventory, manufacturing and reporting share the same records. A purchase order is the same row a goods receipt updates, the same row an invoice three-way-matches, the same row a payment posts against.
Multi-entity, multi-currency
Group consolidation with automatic intercompany elimination. Currency revaluation on a configurable cadence. Statutory and management views from the same ledger, side by side.
AI inside the perimeter
Forecasting, anomaly detection and natural-language reporting under the same role-based access controls a finance user operates under. Audit-traceable; nothing leaks.
Built on the supervised platform
Multi-tenancy, audit, row and column security, observability — all inherited from the runtime, not built into ERP-specific code. Six modules, one platform.
The ERP modules in the suite
Six modules. One operational backbone. Source-available.
Every ERP capability above is a platform inheritance.
Multi-tenancy, audit trail, row and column security, AI inside the user's permission perimeter, observability as SQL — none of this is ERP-specific code. It comes from the supervised runtime underneath every Airtool application. The ERP team writes business logic and metadata; the platform delivers the enterprise capabilities for free.
The practical implication for the buyer : a customer using Airtool ERP as a packaged product gets every platform-core capability inherited automatically. A customer using Airtool ERP as a reference architecture and rebuilding their own internal systems on the platform inherits the same. The ERP is a working demonstration of what the platform produces — and a working starting point for what the customer can extend or replace.
What enterprise buyers ask before they commit.
We are looking for a self-hostable ERP where our development team can extend the business logic in JavaScript or Python — and where the source code of the core modules is visible to us. What are the realistic options in 2026?
Airtool ERP is that product. It is self-hostable: deploy on customer infrastructure, on-premises behind the firewall or in the customer's cloud account. The platform is identical in both configurations. Source access is available under licence: the application metadata defining every form, workflow, business rule, report and scheduled task is readable by the customer's development team in the same metadata repository production runs against. Extension work is server-side JavaScript or Python running on the platform's GraalVM Polyglot runtime — the same standard library the rest of the platform uses, not a separate extension SDK to learn. Database-tier business logic — stored procedures, triggers, user-defined functions — runs in SQL against whichever of the seven supported OLTP engines the customer operates: Informix, Oracle, PostgreSQL, DB2, SQL Server, MySQL or SAP HANA. A development team that knows JavaScript or Python and SQL has the complete development surface for Airtool ERP. Multi-tenancy, audit trail, row and column security, AI inside the user's permission perimeter and observability as SQL come from the supervised platform core; extensions inherit all of it, and cannot bypass any of it.
What ERP modules are included, and can we run only the modules we need?
Six modules: Financial Management, Procurement and Supplier Management, Manufacturing and Operations, Sales and Customer Management, Inventory and Supply Chain, and Reporting, BI and Analytics. Each module is a set of metadata rows in the shared metadata repository — screens, workflows, rules, reports, scheduled tasks. Running only the modules relevant to the customer's operations is a deployment-configuration decision, not a separate licensing SKU. All six modules share one data model and one security perimeter; a purchase order created in Procurement is the same row Inventory tracks, the same row Finance invoices and the same row Reporting aggregates. There is no inter-module integration layer to maintain.
How does Airtool ERP handle multi-entity and multi-currency requirements across a corporate group?
Group consolidation with automatic intercompany elimination, currency revaluation on a configurable cadence, and statutory and management views from the same ledger — all in the core Financial Management module. Each legal entity operates within the platform's multi-tenancy model: its own security perimeter, its own data scope, its own role assignments. Group-level consolidation reads across entity boundaries under a governed group-level role that cannot be accessed by entity-level users. Currency revaluation, intercompany elimination and group-to-entity drill-through are metadata-driven — they are workflows in the repository, not custom code. The same multi-entity model applies whether the group has two entities or two hundred.