Frequently Asked Questions
Fifty straight answers about iDempiere, grouped into six themes: what it is, cost and licensing, implementation, customization and upgrades, our mobile and reporting apps, and support, hosting and security. If your question is not here, ask us directly.
About iDempiere
What the platform is, where it came from, and what it does.
iDempiere is a mature, community-driven open source ERP, CRM and supply-chain suite. It gives a mid-market or larger business one integrated system for finance, sales, purchasing, inventory, warehousing, manufacturing, CRM and projects, all posting to a single accounting engine. It runs on Java, OSGi, the ZK web client and PostgreSQL, and is released under the GPLv2 licence, so the software, database schema and source code are yours. Its defining feature is the Application Dictionary, a metadata layer that lets you reshape windows, fields, rules and workflows by configuring rather than forking, which keeps future upgrades possible even after heavy customization.
iDempiere descends from Compiere, one of the first open source ERPs, by way of the ADempiere community fork. It emerged around 2011 to 2012 when developers rebuilt the platform on an OSGi modular architecture for cleaner extensibility. That lineage matters: the accounting model and Application Dictionary are the product of more than twenty years of refinement. Today iDempiere is an independent community project with regular releases, not a single company's product, which is part of why there is no licence fee and no vendor able to discontinue it or hold your data model hostage.
iDempiere is a Java application built on the OSGi module system, which lets features and customizations load as isolated bundles. The web client uses the ZK Ajax framework, and the database is PostgreSQL or Oracle. Reporting uses BIRT and JasperReports, and a REST API exposes the data model to external systems and mobile apps. This is a proven enterprise stack: PostgreSQL and Java scale comfortably to high transaction volumes, and OSGi is what allows customizations to sit beside the core rather than inside it, which is the technical basis of safe, repeatable upgrades.
iDempiere is maintained by an international community of contributors and implementation companies rather than a single vendor. It has a steady release cadence, active mailing lists and forums, a public source repository and an annual community conference. The community is smaller and more technical than Odoo's, which we state honestly, but it is stable and long-standing. Because the project is genuinely community-owned under GPLv2, no company can take it proprietary or shut it down, which removes a category of vendor risk that proprietary ERP buyers simply cannot escape.
The Application Dictionary is iDempiere's metadata engine. Tables, windows, fields, tabs, validation rules, reference lists, workflows and reports are all stored as data, not hard-coded. That means much of what would be custom programming in other ERPs is configuration here: you add a field, change a validation, adjust a workflow or build a window through the dictionary. Because these changes are metadata rather than core code edits, they survive version upgrades. The Application Dictionary is the single biggest reason iDempiere customizations stay upgrade-safe, and why a super-user can own routine changes.
iDempiere covers 26 integrated modules: financial management, accounts receivable and payable, fixed assets, cash and banking, costing, sales and order management, CRM, purchasing, inventory, warehouse management, manufacturing and MRP, projects, service management, point of sale, HR and payroll, quality, business partners, requests, workflow, reporting, multi-org and multi-currency, security, document management and distribution. Every transaction posts to one Accounting Schema, so there are no interfaces to reconcile between finance and operations. HR and payroll are lighter than the rest, which we address with integration or extension rather than pretending otherwise.
iDempiere fits best where accounting depth, inventory and multi-entity operations matter: manufacturing, distribution and wholesale, third-party logistics, pharma and life sciences, food and beverage, automotive and engineering, retail and eCommerce, and project or service businesses. Its strengths are multi-org, multi-currency accounting, lot and serial traceability, warehouse control and configurable document flows. It is less of a natural fit for businesses whose core need is deep, country-specific payroll, or a heavily vertical process with no willingness to configure. We will tell you honestly if your case is one of those, rather than sell you a poor fit.
iDempiere is fully free under GPLv2 with no Community-versus-Enterprise split, so every feature is available to every deployment. Its accounting is deep, with native multi-org, multi-currency and multi-schema support, and its customization model, the Application Dictionary plus OSGi plugins, is unusually upgrade-safe. Odoo has the best user interface of the three and a huge module catalogue, but its best features sit in a paid Enterprise edition. ERPNext is free and approachable for Python teams. iDempiere's weakest point is its dated interface, which we address with our own mobile and reporting apps. See our full three-way comparison.
Cost & Licensing
Where the money goes when the software itself is free.
The software is genuinely free under GPLv2, with no licence fee, no user count and no module unlocks. You pay for implementation, customization, hosting and support, which is where the real cost of any ERP lives anyway. A typical mid-size iDempiere project costs 40 to 70 percent less over five years than the equivalent SAP or Oracle deployment, almost entirely because of the licence line. There is no catch in the licensing itself; the discipline it demands is a capable implementation partner, since the community does not hold your hand the way a paid vendor's account team does.
iDempiere is released under the GNU General Public License version 2 (GPLv2). In practice this means you may use it for any number of users and companies at no licence cost, you receive the complete source code, and you may modify it freely. The GPL's copyleft terms govern redistribution of the software itself; running it internally and building your own extensions to operate your business carries no fee or obligation to publish. It is one of the most permissive positions in the ERP market for a commercial user, and it is what underpins the whole cost argument for the platform.
You pay for people and infrastructure, not for the software. That means implementation (discovery, configuration, chart of accounts design, data migration, testing and go-live), any customization or integration you need, cloud or on-premise hosting, and ongoing support or application management. These are the same cost lines every ERP carries. The difference with iDempiere is that the licence and annual maintenance lines, often the largest items in a proprietary ERP budget, are simply absent. Your money goes into fitting the system to your business rather than into a vendor's software rent.
For comparable mid-market scope, iDempiere typically lands 40 to 70 percent lower over five years, driven mostly by the removed licence and annual maintenance lines. All such figures are illustrative rather than quoted, because proprietary pricing is confidential and varies by edition, geography and negotiation. Implementation and hosting costs are broadly similar across platforms; the saving is concentrated in software rent and in cheaper, faster customization through the Application Dictionary. Our Pricing and TCO page breaks the model down line by line so you can test it against your own numbers.
No. iDempiere has no per-user, per-seat or named-user licensing, and no charge to switch on a module. Whether you have ten users or a thousand, whether you use two modules or all twenty-six, the software cost is the same: zero. This changes how you roll out ERP, because you can give system access to everyone who would benefit rather than rationing licences. Your costs scale with implementation effort and infrastructure, which you control, not with a per-user meter that grows every time you hire someone new.
No. There are no named-user counts to true up, no indirect or digital access clauses, and no annual compliance letters. A middleware system, a portal or a bot touching iDempiere will never generate a surprise invoice, because there is no licence metric to breach. This removes a genuine budgeting risk that proprietary ERP customers live with, where an integration or a headcount change can trigger an unexpected charge. With iDempiere your software cost is fixed at zero and stays there regardless of how you use it.
No. PostgreSQL is itself free and open source, so the standard iDempiere stack carries no database licence cost. It is a robust, widely deployed database that scales to high transaction volumes, and it is what most of our clients run. iDempiere also supports Oracle if you have a specific reason to use it, in which case Oracle licensing applies, but that is a choice rather than a requirement. For the vast majority of deployments PostgreSQL is the right answer and keeps the whole platform genuinely licence-free.
There is no licence or upgrade fee for the software itself, since new versions are free under GPLv2. What an upgrade costs is the effort to run the migration: applying the version's database changes, and regression-testing your OSGi plugins and Application Dictionary configuration against the new release. Because we never patch the core, that effort is usually a controlled, predictable exercise rather than a project. Clients on a support agreement often have upgrades handled as part of their plan. The point is that upgrades cost time, not licence money.
Yes, and this is one of iDempiere's practical advantages. Because there are no per-user or per-module fees, you can go live with finance and distribution for one entity, then add warehouse, manufacturing, more users, more companies or more countries over time without any licence step-up. Each expansion is an implementation effort, not a purchasing negotiation. This suits growing businesses that want to prove value on a narrow scope first and widen it as confidence builds, rather than committing to a large seat count on day one.
Implementation
How projects run, how long they take, and what your team must supply.
A single-entity finance-and-distribution rollout typically goes live in 4 to 6 weeks. Add manufacturing and you are looking at 6 to 8 weeks. Multi-country, multi-currency consolidations with heavy integration typically run 8 to 12 weeks, phased entity by entity. The variable is almost never the software; it is data quality and how quickly your team can make decisions. Projects that stall usually do so on incomplete master data or slow sign-off, not on iDempiere itself. We size and phase the work up front so a clear, testable scope goes live first and the rest follows in controlled waves.
Five stages. First, discovery and fit-gap: two to four workshops mapping your processes onto iDempiere's document flows, with every gap logged, sized and classified as configuration, extension or integration. Second, a free proof of concept on your own data. Third, build and configure, delivered in two-week sprints with a demo at the end of each. Fourth, migrate and test: master data and open balances loaded, reconciled and signed off across two full UAT cycles plus a dress-rehearsal cutover. Fifth, go live and hypercare, with four weeks of close support before a clean handover into managed services.
Yes. Every engagement starts with a free, scoped proof of concept. You give us a representative slice of your process, typically one product family, one warehouse and one month of transactions, plus your chart of accounts. We configure it, load it and demo it back to you at no cost, so you see your own data running in iDempiere before you commit any budget. It is deliberately concrete: the point is to replace a sales deck with evidence, and to let your finance and operations leads judge the fit on their own numbers.
We migrate in structured stages. Master data first, business partners, products, price lists and the chart of accounts, then open items such as outstanding invoices, purchase orders and stock on hand, and finally opening balances. Data is cleansed and mapped before load, then reconciled against source totals and signed off by your finance team before go-live. We migrate from Compiere, ADempiere, Tally, spreadsheets or legacy databases. The reconciliation step is not optional: we prove that ledgers, stock valuations and open balances match the old system to the rupee, dirham or dollar before cutover.
Yes. We have a GST localization covering CGST, SGST and IGST determination, HSN and SAC coding, e-invoice IRN generation via the IRP, e-way bills, and GSTR-1 and GSTR-3B extracts. It is deployed at manufacturing and distribution clients across India. In practice a posted invoice produces a compliant e-invoice without re-keying into a government portal, which removes a whole class of manual error. The same approach extends to other jurisdictions we serve, such as Gulf VAT, where tax logic is layered on as configuration and OSGi extensions rather than as changes to the core.
Yes, natively and deeply. iDempiere is multi-org, so you can run many legal entities and branches in one instance with shared or separate ledgers and automatic intercompany documents. It is multi-currency, holding transaction, accounting and reporting currencies with revaluation, and it supports multiple accounting schemas so you can keep, for example, a local statutory view and a group IFRS view in parallel. The interface and documents are multi-language. This is exactly the capability that makes it strong for cross-border groups, as in our India-plus-USA consolidation case study.
More than clients expect, and it is the single best predictor of success. You need process owners in finance, sales, purchasing, inventory and any other in-scope area available for workshops, decisions and testing, plus a project sponsor who can unblock decisions quickly. During UAT the commitment peaks, because your people must actually exercise the system on real scenarios. We do the heavy lifting of configuration, migration and development, but an ERP encodes your business rules, and only your team can confirm those rules are right. Under-resourcing internal time is the usual cause of delay.
Three causes dominate: poor master data, slow decision-making, and scope that expands mid-flight. We attack all three. Data is profiled and cleansed early, with reconciliation gates before go-live. Decisions are driven through a single sponsor and logged so nothing stalls in committee. Scope is fixed per sprint, with new requests parked for a later phase rather than absorbed silently. We also insist on the free proof of concept and two full UAT cycles, because most nasty surprises surface when real people run real transactions. None of this is glamorous, but it is what keeps go-live on the calendar.
Yes, and we do it regularly. We start with an assessment of what exists: the configuration, any customizations, the data state and, critically, whether the previous team patched the core or worked in an upgrade-safe way. Where a fork or heavy core patching has been done, we usually recommend a remediation phase to move that work into OSGi plugins and Application Dictionary configuration before proceeding, so the system becomes upgradeable again. We then re-plan the remaining scope realistically. Inheriting another partner's iDempiere is a well-worn path for us, not an exception.
Customization & Upgrades
How iDempiere bends to your business without breaking future upgrades.
If they were built the way we build them, as OSGi plugins and Application Dictionary metadata, they survive. The core is never modified, so a version upgrade is a controlled migration script plus a regression pass on your plugins. Clients who inherited a fork from another partner usually need a remediation project first, moving core patches into proper extensions; we do those too. This upgrade-safe discipline is a policy, not a preference. It is the difference between an upgrade being a planned weekend and being a full re-implementation, which is where many badly built ERPs end up.
Through two upgrade-safe mechanisms. First, the Application Dictionary, where new fields, windows, validation rules, reference lists, workflows and reports are configured as metadata rather than coded. Second, OSGi plugins, which package behavioural code, callouts, model validators, custom processes and document logic, as bundles that load beside the core without altering it. Neither approach touches the base source, so when a new iDempiere version arrives your changes are re-applied and regression-tested rather than lost. The rule we never break is: no core patches. That single policy is what keeps a customized system upgradeable for years.
These are iDempiere's extension points. An OSGi plugin is a self-contained bundle of Java code that iDempiere loads at runtime. A callout is logic that fires as a user edits a field, for example defaulting or recalculating a value the moment something changes on screen. A model validator hooks into document events, such as before a sales order is completed or after an invoice posts, to enforce rules or trigger actions. Custom processes are server-side jobs users can run. All of them live in plugins outside the core, which is why they are upgrade-safe and fully owned by you.
Yes. iDempiere exposes a REST API and supports message-based and database-level integration, so we connect it to eCommerce platforms such as Shopify, WooCommerce, BigCommerce and Magento, to shipping carriers like DHL, FedEx and UPS, to EDI, to payment gateways and bank feeds, and to government systems such as the GST IRP. Our case studies include a Shopify plus multi-carrier integration for a US distributor and a custom customer portal on iDempiere's REST API for a Kuwaiti 3PL. Integrations are built as OSGi extensions, so they stay upgrade-safe like everything else we deliver.
Yes, always. Every line we write is handed over in your own Git repository, documented and with build scripts, so you can compile and deploy it yourself. There are no escrow clauses, no obfuscation and no hostage code. This is a deliberate stance: the whole point of choosing open source is ownership, and it would be hollow if your partner's custom work were locked away. If you ever chose to work with someone else, or to run the system entirely in-house, you would have everything you need to do so.
It is a common situation and a fixable one. The problem with a forked or core-patched instance is that it is effectively frozen: upgrading it means re-doing the patches by hand, so many such systems get stuck on an old version. We assess the extent of the patching, then run a remediation project that lifts the custom behaviour into OSGi plugins and Application Dictionary configuration. Once the core is clean again, the system becomes upgradeable and maintainable on normal terms. It is worth doing, because a frozen ERP slowly becomes a liability.
There is no forced upgrade cycle, since there is no vendor withdrawing support to push you along. In practice we recommend a planned upgrade every one to two years, so you stay close enough to current that each jump is small and you benefit from community fixes and improvements. Because upgrades on a well-built, unpatched instance are a controlled migration plus a plugin regression pass, keeping current is inexpensive. The alternative, letting the system drift many versions behind, makes the eventual catch-up larger and riskier, so little and often is the sensible rhythm.
Many changes, yes. Because so much of iDempiere is Application Dictionary metadata, a trained super-user can add fields, adjust validation, change reference lists, tweak workflows and build or modify reports without writing code. Our Lebanon training case study was exactly about giving a client's own team that self-service capability. Deeper work, callouts, model validators, complex processes and integrations, needs a developer working in OSGi plugins. We are happy to draw the line wherever suits you: some clients own routine configuration and call us for the hard parts, others prefer we handle everything.
Our Mobile App & Reporting App
The two products we built to fill the gaps in the community core.
They are our own products, iDempiere Mobile and Dashboards & Analytics, delivered as part of an implementation or licensed separately if you already run iDempiere with another partner. Pricing is per deployment, not per user, and the source is available to you, in keeping with the open ethos of the platform. They exist because the community core has no native mobile client and its built-in reporting is developer-oriented; these two apps fill exactly those gaps. Talk to us about which commercial model fits, since it differs slightly between a fresh implementation and an add-on to an existing system.
iDempiere Mobile puts the ERP in your team's hands for the tasks that happen away from a desk. It captures sales orders with live price lists, performs real-time stock enquiry across warehouses, drives barcode and QR picking, packing and despatch, confirms goods receipts and deliveries, handles workflow approvals with push notifications, and captures expenses with photo attachments. Screens are role-based, so each user sees only their work. In our UAE and Kuwait 3PL case studies it took the warehouse floor off paper, which is where much of the accuracy gain came from. It syncs straight into iDempiere over its REST API.
iDempiere Mobile is a single Flutter application that runs natively on both Android and iOS, so you get near-native performance from one codebase and a consistent experience across phones and tablets. Android is the common choice for rugged warehouse devices and scanners, while iOS suits field sales and management. Because it is one app rather than two separate builds, feature updates arrive together on both platforms. It talks to your iDempiere instance over the REST API, secured with the same roles, organisations and permissions you have already configured in the ERP.
Yes. iDempiere Mobile includes an offline queue so that work can continue when connectivity drops, which is common in large warehouses, cold stores and remote sites. Actions are captured locally and synced to iDempiere when the connection returns, with conflict-safe handling so two devices cannot silently overwrite each other. This matters in real operations: a picker deep in a racking aisle should not stop because the Wi-Fi is weak. The app is designed so that the floor keeps moving and the ERP catches up, rather than the ERP dictating that the floor waits for a signal.
iDempiere Mobile authenticates against your iDempiere instance and operates under the same role, organisation and permission model you configured in the ERP. A user sees only the warehouses, documents and actions their role allows, exactly as they would in the web client, so there is no separate, weaker permission scheme to manage. Traffic runs over secured connections, and because the app is a thin client over the REST API, business rules and validation stay enforced on the server. You administer access once, in iDempiere, and the mobile app inherits it rather than duplicating it.
Dashboards & Analytics is a separate reporting web application that reads iDempiere without slowing it down. iDempiere's built-in BIRT and JasperReports are capable but developer-oriented, and running heavy reports directly against the transactional database competes with order entry. Dashboards & Analytics gives finance and operations users a drag-and-drop report builder, drill-down from KPI to source document, scheduled distribution as PDF, Excel or CSV, and consolidated multi-org, multi-currency views, all reading from a replica or read-only connection. It is the self-service, low-impact analytics layer the core lacks, and it is why our clients stopped dreading month-end reporting.
No, and avoiding that is its whole reason for existing. Running month-end and analytical queries inside a live transactional ERP punishes everyone using it. Dashboards & Analytics reads from a database replica or a read-only connection, so heavy reporting never locks up order entry or slows the people doing day-to-day work. In our USA distribution case study, moving reporting onto a replica was exactly what made the finance close faster and calmer. You get consolidated dashboards and detailed reports with effectively zero load on the production database that keeps the business running.
Yes. Dashboards & Analytics can run existing BIRT and JasperReports definitions, so the report investment you have already made is not thrown away. You can keep pixel-perfect statutory and document layouts in those engines while using the self-service builder for exploratory and management reporting. Row-level security mirrors iDempiere roles, so users see only the data they are entitled to, and output distributes on a schedule as PDF, XLSX or CSV. The aim is a single reporting surface that respects your existing definitions and adds fast, drill-down analytics on top rather than forcing a rebuild.
Support, Hosting & Security
Running iDempiere safely in production, and keeping your options open.
We provide SLA-backed application management services (AMS): incident response, month-end assistance, patching, performance tuning and enhancement sprints. Plans range from light-touch, where we back up an internal team that owns day-to-day operation, to full managed service where we run the platform end to end. Support covers the iDempiere core, our mobile and reporting apps, and any customizations and integrations we or others built. Because you own the source, support is a service relationship rather than a dependency: you are free to move it in-house or elsewhere, which keeps the relationship honest.
Anywhere you like, which is another benefit of owning the software. We deploy Dockerised iDempiere on AWS or Azure, on other cloud providers, or on your own on-premise servers. A typical cloud setup uses high-availability PostgreSQL, automated backups, monitoring and a tested disaster-recovery plan. On-premise suits clients with data-residency requirements or existing datacentre investment. Because the stack is standard, Java, OSGi and PostgreSQL, you are not locked to a single hosting vendor and can move between environments. We recommend an architecture based on your uptime needs, data-residency rules and budget rather than a one-size template.
Backups are automated and regular, covering the PostgreSQL database and the application configuration, with retention set to your policy. Just as important, we test restores, because an untested backup is only a hope. For disaster recovery we design to your recovery-time and recovery-point objectives, using replication and, where justified, a standby environment that can be brought up quickly. On-premise deployments get the same discipline adapted to your infrastructure. The principle is that recovery is a rehearsed procedure with known timings, not an improvisation on the worst day, and we prove it works rather than assuming it does.
iDempiere provides a mature security model: role-based access, organisation-level scoping, and record- and field-level control, plus a full audit trail of changes. Being open source is a security strength rather than a weakness, because the code is open to inspection and community scrutiny rather than relying on obscurity. We harden deployments with secured connections, controlled network access, least-privilege database accounts, timely patching and monitoring. You also control where the data lives, on your chosen cloud or on-premise, which helps with data-residency and compliance obligations. Security is a combination of the platform's model and disciplined operation, and we handle both.
Access is governed by roles, which grant or deny windows, tabs, fields, reports and processes, combined with organisation access so a user is confined to the entities and branches they should see. Beyond that, iDempiere supports record-level access rules and data-access controls, so you can restrict individual records or categories of data to particular roles. This is granular enough to run many legal entities in one instance with each user seeing only their own scope, which is exactly what makes the multi-org and multi-client 3PL deployments in our case studies safe. You administer it centrally, and our apps inherit it.
Response times are tiered by severity and agreed in your support contract. A critical, production-down incident gets the fastest response and continuous work until service is restored; lower-severity issues and enhancement requests are scheduled against agreed targets. We serve clients across the Gulf, Europe, the USA and APAC from teams in India, with overlap hours arranged so you are not waiting a day for a first response. Rather than quote fixed numbers here that may not match your needs, we set severity definitions and target times together, so the SLA reflects your operational risk rather than a generic template.
You can, cleanly, and that is by design. You already hold the iDempiere source, your database on open PostgreSQL, and every customization and integration we built in your own Git repository, documented and buildable. There is no proprietary lock, no escrow to release and no data you cannot extract. A handover to an internal team or another partner is a knowledge-transfer exercise, not a hostage negotiation. We think this is the right way to earn a long relationship: we keep your business because the work is good, not because leaving would be painful. Low exit cost is a feature.
Yes. We run structured functional and technical training, as in our Lebanon case study, so your team can own day-to-day configuration and even build their own extensions. The functional track covers document flows, the Accounting Schema and Application Dictionary configuration; the technical track covers OSGi plugins, callouts, model validators and BIRT or JasperReports development, with hands-on exercises on a sandbox. Because we teach the upgrade-safe patterns from the start, what your team builds stays compatible with future versions. Many clients run a hybrid model afterwards: internal ownership of routine work, with us on call for design review and complex tasks.
Still have a question we did not answer?
Ask us directly, or see iDempiere running on your own data with a free, scoped proof of concept.