Open Mercato vs Odoo: The Feature Comparison, Checked Against Primary Sources

Both of these platforms are open source, which is where most comparisons of them stop. The differences that decide a project sit lower down: who writes the last 20% of the system, who owns the database it runs on, and what a paid tier buys you. Every claim below is sourced from a document you can open. Odoo's side comes from its documentation for version 19, its licence file and its editions page. Open Mercato's side comes from its documentation, release notes, specifications, module registry and repository. The Polish e-invoicing dates come from the Ministry of Finance.

If you are looking for an Odoo alternative for a manufacturing or operations-led business, the rows below are the ones that decide it. We ran the same exercise against a very different kind of vendor in Open Mercato vs Salesforce, and the questions that separate the platforms turn out to be the same three.

We build custom software for manufacturers and operations-led companies, and we are a certified Open Mercato implementation partner, so we are an interested party in one of these columns. Every row carries its source for that reason, including the rows where a source contradicts something that would flatter us.

The short verdict

• Category — Odoo: application suite, dozens of finished apps. Open Mercato: platform foundation with 43 domain modules in the released core, covering roughly 80% of the infrastructure a custom business system needs.
• Licence — Odoo: Community under LGPLv3, Enterprise licensed commercially, per user. Open Mercato: core MIT licensed with no per-seat fee, plus an optional paid Enterprise Edition subscription carrying five proprietary modules, MFA and SSO among them, and a certification path.
• Hosting — Odoo: Odoo Online, Odoo.sh or self-hosted. Open Mercato: your database and your infrastructure if you want it.
• Warehouse management — Odoo: shipping as the Inventory app. Open Mercato: shipping as the wms module: warehouse topology, inventory balances, reservations and a movement ledger.
• Statutory accounting — Odoo: shipping, with a Polish fiscal localisation. Open Mercato: designed and specified, with the ledger staying in your accounting system for now.
• Polish KSeF e-invoicing — Odoo: shipping inside the fiscal localisation, generating the FA(3) structure in force since February 2026. Open Mercato: a partner module talking to the official API, whose shipping release still emits the retired FA(2) structure.
• Self-service reporting — Odoo: pivot and graph views on any list, Spreadsheet BI in Enterprise. Open Mercato: dashboard widgets per role and a documented export on every list endpoint, with analysis in a BI tool over your own database.
• Field-level access control — Odoo: yes, by group on the field. Open Mercato: role, feature and organisation scoping, plus per-tenant field-level encryption.
• Multi-entity — Odoo: several companies in one database, upsell to the Custom plan on Standard. Open Mercato: multi-tenant by default, with organisation hierarchies and automatic scoping on the entities that carry tenant and organisation ids, which is most of the data model.
• AI — Odoo: Ask AI plus agents that act through configurable tools, with the guardrail written in your own Python. Open Mercato: agents inheriting the operator's own permissions, three declared modes, approval card with a field diff on every write.
• Ecosystem — Odoo: very large app store and hiring market. Open Mercato: modules published on the package registry by named agencies, and a certified partner directory of 27.

Odoo is ahead wherever you want a finished application to switch on, and its statutory accounting and reporting depth are the clearest cases. Open Mercato is ahead wherever the process you compete on has to be encoded rather than configured, in what an agent is allowed to do, and in what you own at the end.

Feature by feature

The rows below come from each vendor's own documentation where it exists, and from the Open Mercato repository, its specifications and the package registry where the documentation has not caught up with the product yet. That second category matters: several capabilities in the platform, warehouse management among them, are visible in the repository and absent from the marketing pages.

Category and licence

• What you get on day one — Odoo: 633 modules in the addons directory of branch 19.0, covering sales, accounting, inventory, manufacturing, HR, point of sale and website as finished apps. Open Mercato: 43 modules in the released core plus 25 supporting packages alongside it, from authentication and RBAC to CRM, quoting, warehousing and compliance. The core is MIT licensed, and 18 of those modules declare themselves ejectable into your own application.
• Core licence — Odoo: LGPLv3 for Community, and the Community source is public in odoo/odoo. Open Mercato: MIT for the core, stated in the README as "is and always will be MIT Licensed, fully Open Source".
• What the paid tier buys — Odoo: hosting, version upgrades, functional support, mobile apps, Spreadsheet BI and Payroll. The Enterprise code itself is not published, so those modules cannot be read before you license them. Open Mercato: five proprietary modules the open-source distribution does not carry (multi-factor authentication, SSO with SAML/OIDC and SCIM directory sync, record locking, auth login interceptors, system status overlays), a certification path of architecture audit, security, performance and custom-code reviews and homologation, and a priority helpdesk its own README calls AI-assisted. The certification items start at the middle tier rather than the entry one. Running the software does not require any of it, though the vendor writes that "uncertified Open Mercato deployments should not go to production".
• Who writes the last 20% — Odoo: configuration, then Python modules. Open Mercato: TypeScript modules with overlays discovered at runtime.

With a suite you inherit somebody else's model of your business and configure around it. With a foundation you encode your own model. Companies whose advantage lives in a process, a configuration engine or a fulfilment flow tend to reach the ceiling of a suite in year two, and that ceiling is where our projects usually start.

What ships in the core today

We read this off the released tag, because the marketing page undercounts it. Version 0.7.0 carries 43 modules in the core and 25 supporting packages alongside it. Thirty-one of those modules also state an MIT licence in their own metadata, and eighteen declare ejectable: true, which is the flag that copies a module into your application for you to own. The descriptions below are the modules' own words.

• Sell and fulfil — sales ("quoting, ordering, fulfillment, and billing capabilities built on modular pricing and tax pipelines"), catalog (products, variants and pricing for the sales module), shipping_carriers, payment_gateways (adapter contract, registry, transaction tracking, webhook routing).
• Warehouse — wms (warehouse topology, inventory balances, reservations, movement ledger).
• Customers — customers (people, companies, deals and activities), customer_accounts, portal (self-service customer portal), communication_channels, messages, inbox_ops.
• After sales — warranty_claims (warranty, return, core-return and vendor-recovery claims desk).
• People and capacity — staff (teams, roles, employee rosters), planner (availability schedules and shared planning rules), resources (assets and resources).
• Automation — workflows, business_rules (engine for defining, managing and executing business logic and automation rules), notifications, push_notifications.
• Compliance — eudr (EU Deforestation Regulation: product commodity mappings, supplier origin evidence, due diligence statements), audit_logs.
• Data in and out — data_sync, sync_excel (file-upload CSV import on the data-sync hub), integrations, api_docs, api_keys, query_index.
• Platform — core, auth, directory, entities, dictionaries, configs, currencies, translations, feature_toggles, dashboards, widgets, perspectives, attachments, devices, progress, design_system.

The supporting packages carry the plumbing you would otherwise buy or build: scheduler, queue, search, webhooks, cache, storage-s3, checkout, gateway-stripe, sync-akeneo for product data, channel-gmail and channel-imap for mail, three push channels, ai-assistant, content, onboarding, telemetry and the enterprise package that holds SSO, MFA and record locking.

Two absences belong in the open here, because they are the rows where Odoo answers and this platform does not. There is no financial, accounting or pos module in the released core, and none on the development branch either. Statutory accounting exists as a specification, which the KSeF section covers, and point of sale is specified in the same way. Everything else above is code in the release, with 164 specifications marked implemented at that tag.

Polish KSeF and statutory accounting

• Filing to the national system — Odoo: inside the fiscal localisation, FA(3) XML generated and submitted for validation, the Official Receipt Certificate (UPO) retrievable on the invoice, vendor bills fetched from KSeF every three hours. Open Mercato: @fastwhitecat/integration-ksef-direct from certified partner Fast White Cat, talking to the Ministry of Finance REST API v2 with no middleware in between.
• Edition needed — Odoo: the Polish e-invoicing module l10n_pl_edi, titled "Polish E-Invoicing FA(3)", is LGPL-3 in the Community addons directory and auto-installs with the Polish localisation, so filing does not sit behind Enterprise. Open Mercato: a partner module on top of the MIT core.
• Installation — Odoo: install the localisation modules. Open Mercato: npm install @fastwhitecat/integration-ksef-direct, because the built-in mercato module add command only accepts official @open-mercato/* packages.
• What the module covers — Odoo: invoice submission, status, receipt certificate, inbound import. Open Mercato: invoice submission, status polling, KSeF reference numbers, inbound synchronisation, connection and rate-limit health checks, test and production endpoints behind one configuration.
• General ledger, payables, receivables, fixed assets — Odoo: shipping. Open Mercato: specified, with country plugins for Poland described in the financial specification.

Both mandate dates have passed, so a filing path is a live obligation rather than a roadmap item. Per the Ministry of Finance, structured invoicing became mandatory "od 1 lutego 2026 r." for businesses whose 2024 sales including VAT exceeded 200 million PLN, and "od 1 kwietnia 2026 r. dla pozostałych przedsiębiorców", with reliefs running until the end of 2026 where monthly documented sales stay at or below 10,000 PLN.

Three points of diligence to close before anyone signs anything, because we would rather raise them than have your finance team find them.

• Schema version, and this one is a blocker rather than a caveat. The Ministry is explicit that "od 1 lutego 2026 r. struktura logiczna FA(3) zastąpiła strukturę logiczną FA(2)", with FA(2) accepted only to 31 January 2026. The shipping module still builds FA(2): its own feature list says so, and the compiled XML builder in version 0.1.7 writes the FA(2) namespace http://crd.gov.pl/wzor/2023/06/29/12648/ with <WariantFormularza>2</WariantFormularza>, where FA(3) is http://crd.gov.pl/wzor/2025/06/25/13775/. On what is published today, that path does not file a compliant invoice. Ask Fast White Cat for a released FA(3) build and a date, and make it a condition of the contract.
• Platform version. Read the scope carefully, because two of them exist in the registry. The maintained package is @fastwhitecat/integration-ksef-direct, version 0.1.7 published 1 September 2026, declaring support for Open Mercato >=0.7.0 <0.8.0, which is the current release. The older hyphenated scope @fast-white-cat/integration-ksef-direct stopped at 0.1.2 in June and pins >=0.6.4 <0.7.0, so installing that one holds your platform a release back.
• Licence. The module is published as Proprietary, with no licence field in the registry metadata. That is a normal commercial arrangement, and it is a different one from the MIT terms of the core, so put it in the contract instead of assuming it.

The target architecture works in most of our clients' favour once the schema gap closes: structured invoicing to the national system runs on the platform, and the ledger stays in the accounting system the finance team refuses to replace, with reconciliation over documented APIs. Until the maintainer ships FA(3), we scope the filing path around the tool your finance team already files with, and we say that in the first call rather than in month four.

Reporting and analytics

• Ad-hoc cross-tabs for managers — Odoo: pivot and graph views wherever a report exposes them, which Odoo documents as varying by report, with selectable measures, grouping, sorting by measure and an .xlsx download of the pivot. Open Mercato: analysis belongs in a BI tool over your own database.
• Dashboards — Odoo: included. Open Mercato: dashboard widgets assignable per role, with per-user overrides for individuals.
• Export — Odoo: .xlsx from list views. Open Mercato: CSV, JSON, XML or Markdown on every list endpoint, by adding a format parameter to the URL the grid already uses.
• Spreadsheet BI — Odoo: Enterprise editions. Open Mercato: whatever BI tool you already run.

Odoo wins this row for a non-technical manager who wants a new report before lunch. What Open Mercato gives you instead is unmediated access: the database is yours, and reading it does not depend on which pricing plan you are on.

Budget that layer in phase one and the trade works in your favour, because a warehouse fed straight from your own tables outlives any vendor report builder. Discover it late and it arrives as an unplanned line item, which is the failure mode Panorama Consulting measures in its 2026 ERP Report: more than a quarter of organisations exceeded their project budgets, and additional technology needs led the causes. The same report puts business intelligence in substantial use at 55.3% of organisations, so a reporting layer is close to a default expectation rather than an extra.

Access control

• Permission sets — Odoo: groups. Open Mercato: roles with feature-based permissions and feature flags.
• Model-level rights — Odoo: create, read, write and unlink per model. Open Mercato: per-feature grants, with additive per-user overrides.
• Row filtering — Odoo: record rules, as global or group rules. Open Mercato: automatic scoping by tenant and organisation on the entities that carry those ids.
• Hiding one field from a colleague who can open the record — Odoo: yes, through a groups attribute on the field. Open Mercato: absent.
• Encryption of sensitive fields — Odoo: not covered in the security reference for version 19. Open Mercato: field-level AES-256-GCM in the ORM lifecycle, with a 256-bit data-encryption key generated per tenant and held in a key management service, HashiCorp Vault by default, in the core rather than behind the paid tier.

These are two different controls for two different threats. Encryption protects data from whoever reaches the storage. Field-level security protects one field from a colleague at the next desk with a legitimate login.

If a commercial margin or a salary figure must stay invisible to a role that needs the rest of the record, Odoo does that today and we say so in the first call. It disqualifies fewer projects than it sounds, because most of our clients need whole records hidden from whole roles, which role and organisation scoping does cleanly, and they need the encryption story for the data that leaves the building.

Audit trail and undo

• Change history — Odoo: tracked fields in the record chatter. Open Mercato: action log of create, update and delete events with the actor and the tenant scope.
• Detail per entry — Odoo: previous and updated values on tracked fields. Open Mercato: before and after snapshots with a field-level diff.
• Accounting-grade trail — Odoo: a dedicated audit trail report, described as satisfying the requirements of financial authorities and auditors, with an optional restrictive mode under which tracked records can only be cancelled or archived. Open Mercato: covered by the same action log, with access log retention configurable by environment variable, seven days for core resources and eight hours for the rest by default.
• Reversing a write — Odoo: cancel or archive. Open Mercato: undo ships for directory tenants and organisations, auth users and roles, with other modules opting in through command handlers carrying undo snapshots. The button is enabled for the most recent undoable entry, to guarantee replay order.

Neither platform reverses an external integration. Open Mercato records a per-write action log with before and after snapshots and a diff, and extending undo to your own entities is an exercise in your own code. Odoo documents an audit trail in Accounting; check how far it reaches into the apps you actually run before you treat either row as settled.

Customisation and upgrades

• No-code layer — Odoo: Studio for fields, views, models, automation rules, webhooks, PDF reports and approval rules. Open Mercato: custom entities with declared fields, validators and UI widgets, managed live from the admin.
• Code layer — Odoo: Python modules. Open Mercato: TypeScript modules with overlays discovered at runtime, per-module migrations, dependency injection per request.
• Effect on upgrades — Odoo: Odoo covers Studio customisations under its upgrade SLA while Studio stays installed and the subscription stays active. Custom and third-party modules sit outside that, unless you buy a maintenance-of-customisations subscription, and those are what turn an upgrade into a project. Open Mercato: overlays keep your code outside core files, so platform updates land without unpicking your work.
• Support horizon — Odoo: "Each major version is supported for three years", then "you will have another two years to complete the upgrade". On Odoo Online an upgrade is mandatory every two years on a major version, and a few weeks after the next release on a minor one. Open Mercato: releases every few weeks, with modules ejectable into your own application.

Installing Studio in a database on the Standard pricing plan automatically triggers an upsell. The external API is a harder line: Odoo documents it as available only on Custom plans, and not available on One App Free or Standard. The deeper trade is the one above: on a suite, every customisation you add today is a line item in the next mandatory upgrade, and on a foundation more of the application is yours to write in the first place. That compounding is the same mechanism we described in technical debt in AI platforms: the cost arrives on a schedule somebody else sets.

AI

• What ships — Odoo: Ask AI across the database, plus an AI app where each agent carries a system prompt, topics, tools and sources. The default is stated plainly: "If an agent is not assigned any Topics, it is only able to provide information, not complete tasks or make changes to the database". Open Mercato: assistants scoped to one domain, seeing only the records the operator sees, because they inherit that person's roles and permissions.
• Can it write — Odoo: yes, once an agent has topics and tools. The docs are precise about the default: "The standard Ask AI agent cannot make changes to the database", and equally precise about the extension: tools "are the functions the agent can perform in Odoo. These include actions like creating a lead", with Create Leads shipping as a preconfigured topic. Open Mercato: yes, under three declared modes: read-only, confirm-required and destructive-confirm-required.
• Where the guardrail lives — Odoo: in code you write. An AI server action "does not enforce business rules, modify records directly, or guarantee the correctness of the operation"; the tool it calls "must enforce business rules explicitly in Python code" and "will execute unconditionally, unless the code itself prevents it". Open Mercato: in the platform. Every write is staged as a proposal card with a field-by-field diff and a Confirm button, expiring after fifteen minutes of inactivity.
• Scope of what an agent may touch — Odoo: whatever the tool's Python allows. Open Mercato: the operator's own roles and permissions, inherited per assistant.
• Administrator control — Odoo: system prompt, topics, tools, sources and response style per agent, with an option to restrict an agent to its uploaded sources. Open Mercato: an administrator can tighten an assistant and cannot loosen it beyond what the shipped agent declares.
• Model provider — Odoo: "Odoo supports multiple versions of both ChatGPT and Gemini". Open Mercato: Anthropic, OpenAI or Google with your own key, plus OpenAI-compatible endpoints, including local servers such as LM Studio and Ollama for development and offline work.
• Protocol support — Odoo: not documented in the AI documentation for version 19. Open Mercato: MCP listed among the platform's AI capabilities, plus an Agent Orchestrator described as running "AI agents in production with workflow integration, audit trails, and human-in-the-loop controls".

Both platforms let an agent change your data, so the question worth asking is where the brake sits. In Odoo it sits in the Python of each tool you expose, and the documentation says so without softening it: the AI picks the tool and the arguments, the tool executes unconditionally unless its own code stops it, and enforcing business rules is the tool author's job. That is a workable design for a team with developers on hand and a review habit, and it puts the safety of your records in code somebody has to write and maintain.

In Open Mercato the brake sits in the platform. The assistant inherits the roles of the person using it, so it cannot reach records that person cannot open, and a write arrives as a card showing every field before and after with a Confirm button. Nothing has to be coded for that to be true on the first day.

If agents acting on business records are part of your plan, this is the row to prove in a pilot on your own data, and the comparison comes down to a guardrail you build against a guardrail you inherit. We set out what that governance has to cover before an agent touches production records in AI-native ERP governance.

Multi-entity and integrations

• Several legal entities — Odoo: multiple companies in one database, records shared or restricted per entity, inter-company transactions documented. Enabling it inside a Standard database automatically triggers an upsell to the Custom plan. Open Mercato: multi-tenant by default, with organisation hierarchies, and automatic scoping by tenant and organisation on the entities that carry those ids, which the README describes as most of them.
• Serving external organisations — Odoo: portal users. Open Mercato: self-service portals for customers and partners, with the same scoping model.
• API — Odoo: external API, documented as available only on Custom plans and not available on One App Free or Standard. Open Mercato: open REST with a generated OpenAPI document served by the app.
• Events and webhooks — Odoo: automation rules and webhooks. Open Mercato: domain events with persistent subscribers, local or Redis-backed; webhooks with one-time signing secrets, retry attempts and delivery logs, verified by the consumer on webhook-id, webhook-timestamp and webhook-signature; a data-sync API covering integration metadata, credentials, logs and the sync run lifecycle.

Scoping carried in the data model is the stronger isolation guarantee when you also serve external organisations such as a dealer or partner network, because the boundary sits on the records themselves rather than in configuration you can misconfigure.

Ecosystem and people

• Marketplace — Odoo: "40k+ community apps" and "28 million happy users", both figures stated on Odoo's own home page and not independently audited. Open Mercato: modules published on the package registry by named agencies.
• What is published today — Odoo: apps across every business domain. Open Mercato: the official carrier integration (InPost), a configure-price-quote engine, a recurring billing engine with a connector between the two, Shopify and Google Sheets data-sync adapters, a Cloudflare email channel, health-check endpoints, a Strapi integration and the KSeF module above.
• Reading before installing — Odoo: the 633 Community modules are public and LGPLv3. The Enterprise repository is not public, so Studio, Spreadsheet BI and Payroll are bought before they are read. Open Mercato: every module in the core ships as source you can read before you install it. Third-party modules set their own terms: the KSeF module above is proprietary.
• Partners — Odoo: 4,389 partners worldwide in Odoo's own directory, of which 17 are in Poland, two of them at Gold level, as of 3 September 2026. Open Mercato: 27 certified agencies in the partner directory as of 3 September 2026, all of them based in Poland.
• Release cadence — Odoo: annual major versions. Open Mercato: 0.7.0 on 26 August 2026, after 0.6.7 on 5 August, with work published on the development channel as recently as 8 September.

The ecosystem asymmetry is real and it favours Odoo on volume. The Open Mercato ecosystem lives on the package registry rather than in a marketplace page, so it reads smaller than it is, and the partner concentration in Poland matters for a Polish buyer, because the February and April filing deadlines apply to those companies first.

Hiring is the asymmetry we cannot argue away, and it runs on a longer timescale than either directory. Odoo has been shipping for well over a decade, so the pool of developers who have already worked in it is deeper than the pool briefed on a platform released this year, and that gap does not close because a directory says otherwise.

The directories still repay reading side by side, because they say something a feature grid does not. Odoo lists 4,389 partners worldwide and 17 of them in Poland. Open Mercato lists 27, all in Poland. For a company in Warsaw or Gdansk choosing between the two, local implementation capacity is not the constraint people assume it is, and the deeper labour market and the closer partner bench point in opposite directions. What travels in both cases is the code: an Open Mercato application is yours under MIT, so a competent TypeScript team can pick it up. That partner work is our business, so weigh those sentences for what they are and price the dependency instead of meeting it in month four. What to ask any agency before you sign is in working with a software agency.

How we de-risk a platform decision

Do you require five years of production references from a platform vendor? If yes, Open Mercato is the wrong choice and we tell you that in the first call. That is a procurement rule, and no architecture argument beats it. Buyers without a CTO in the room usually need one more layer of questions, which we set out in how to buy custom software without a CTO.

If not, three properties do the de-risking, and they hold on day one rather than being negotiated later. The core is MIT, so a project you fund stays runnable whatever happens to any company around it. Your customisations live in overlays outside core files, so you are not holding a fork. And modules can be ejected into your own application, which means the exit path is part of the design.

One scope boundary stays on the table, and it is the one we raise ourselves. Complex configure-to-order products with nested rules and CAD or bill-of-materials output get named in discovery: built on the platform, routed to the partner CPQ engine, or connected to a mature configurator you already run. Where those rules should live in either case is the subject of defining configuration rules once. You get our answer on which of the three during discovery, in writing. Statutory accounting is the other, and the KSeF section covers it.

Odoo's risks sit in the opposite place. Feature gating between Community and Enterprise, per-user licensing that grows with headcount, mandatory upgrades on the hosted tier, and upgrade effort proportional to how much you customised. Those shape your five-year commitment without threatening the project's existence.

Where the trade-off lands

Odoo's advantage matters when the dependency is finished functionality: statutory accounting your accountant already knows, a pivot table a manager builds without a developer, an app for a domain you have no intention of designing yourself, and a hiring market you can recruit from next month.

Open Mercato's advantage matters when your dependency is the process. A quoting or configuration flow that decides why customers pick you, orders re-typed between systems, external organisations needing scoped access, agents expected to act on records under the same permissions as people, and a data model you want to own outright. That advantage assumes a technical partner in the picture, in-house or hired, because the platform ships as code.

Mapping which of these dependencies you have takes less time than either column suggests. Put every system you run on one page, including the spreadsheets and the manual steps, then mark which of them your competitors also run. The method is in how to map your software ecosystem before any integration project, and the exercise takes an afternoon.

Whatever you mark as ordinary can live in a suite. Whatever you mark as yours alone is the case for a foundation. If the ordinary half includes statutory accounting and the half that matters is your quoting, configuration or fulfilment process, run both and connect them over documented APIs. We recommend that split even when it is smaller than the project we could otherwise scope. Book a welcome coffee if you want the two columns applied to the systems you actually run, including the rows where the answer is Odoo.

Frequently Asked Questions

Can Open Mercato file invoices to KSeF today?

The plumbing is there and the compliance is not, so the useful answer is no on what is published today. @fastwhitecat/integration-ksef-direct from Fast White Cat, version 0.1.7 and supporting the current 0.7 platform release, talks to the Ministry of Finance REST API v2 directly with no middleware, sends invoices, tracks submission status and reference numbers, synchronises inbound invoices and monitors the connection and rate limits. Its shipping build emits FA(2), which the Ministry retired on 31 January 2026 in favour of FA(3), so ask the maintainer for a released FA(3) build and a date before you plan a filing path around it. The module is also published proprietary rather than under the MIT terms of the core. Statutory accounting is a separate question: that module is specified rather than released, so the ledger stays in your accounting system for now.

Is Open Mercato an Odoo alternative for a manufacturer?

It replaces a different part of the problem. Odoo gives a manufacturer finished apps, including statutory accounting and a pivot builder a manager can use unaided. Open Mercato gives a foundation: 43 modules in the released core, warehousing among them, with the last 20% written as your own TypeScript modules. If what makes you money is a quoting, configuration or fulfilment process, the foundation is the closer fit and the ledger can stay where your accountant already works. If your dependency is finished functionality across every domain, the suite is. Statutory accounting and complex configure-to-order are the two boundaries we put on the table during discovery.

Is Odoo Community enough, or do we need Enterprise?

Community gives you the applications and the LGPLv3 licence. Hosting, version upgrades, functional support, mobile apps, Spreadsheet BI and Payroll sit in Enterprise, per Odoo's editions comparison. Check your must-have list row by row against that page before committing to Community, because the gap sits in services and a handful of features, not in the applications themselves.

Does Open Mercato need a paid licence to run?

No. The core is MIT licensed and stays that way, with no per-seat fee. The Enterprise Edition subscription is a separate commercial agreement covering five proprietary modules the open-source distribution does not carry (multi-factor authentication, SSO with directory sync, record locking, auth login interceptors and system status overlays), a certification path of architecture audit, security, performance and custom-code reviews and homologation, and a priority helpdesk its own README calls AI-assisted. Read the tier table before you budget, because the architecture audit and the homologation start above the entry tier. It is a decision about assurance rather than about the right to run the software, though the vendor states that uncertified deployments should not go to production, so read that position before you plan to skip it.

Which one is cheaper?

The question that produces a useful answer is what each platform costs you over three years, including implementation, the reporting layer, integrations, statutory compliance work and the people who maintain the system. How to frame that number so it survives a board meeting is in measurable ROI on ERP and CRM modernisation. Licence models differ so much that comparing them alone is how software budgets get missed. We put the numbers for a specific scope in a proposal, where they can carry assumptions.

Can we migrate from Odoo to Open Mercato later, or the other way?

Both platforms export their data and document their APIs, so the data model translation is feasible in either direction. The work that consumes the budget is mapping custom fields, deduplicating records and reconciling history, and it is project work regardless of tooling. Any partner who calls a migration a configuration exercise, including us, should be asked for the hours.

Who implements Open Mercato?

The certified partner directory lists 27 agencies as of 3 September 2026, all of them based in Poland, and we are one of them. The question worth asking any of us is what we have contributed to the core and what we have delivered in your industry, not which page lists us as a partner.

Sources

Fetched or verified on 4 August 2026, with platform status, release data and the partner directory re-verified on 3 September 2026.

• Ministry of Finance, KSeF legal basis and key dates (government primary)
• Panorama Consulting Group, 2026 ERP Report release (independent industry research)
• Odoo, LGPLv3 licence, branch 19.0, Community versus Enterprise, pricing and plans (vendor primary)
• Odoo documentation 19.0: security reference, Poland fiscal localisation, Studio, reporting, accounting reporting and audit trail, upgrade policy, external API, multi-company, AI, view types (vendor primary)
• Open Mercato, repository and README, release notes, official modules (project primary)
• Open Mercato source at tag v0.7.0: module metadata in packages/core/src/modules/*/index.ts (titles, descriptions, licence and ejectable flags), package list under packages/, and .ai/specs/implemented/ for the implemented specification count (project primary, read 3 September 2026)
• Odoo source, branch 19.0: the addons directory (633 modules) and the l10n_pl_edi manifest ("Polish E-Invoicing FA(3)", LGPL-3). The Enterprise repository is not publicly readable (vendor primary, read 3 September 2026)
• Odoo AI documentation source, branch 19.0: agents (topics, tools, preconfigured Create Leads) and AI server actions ("perform record updates, moves, or writes", "will execute unconditionally, unless the code itself prevents it") (vendor primary, read 3 September 2026)
• Odoo, partner directory and its Poland filter, 4,389 partners worldwide and 17 in Poland (vendor primary, checked 3 September 2026)
• Open Mercato documentation: audit and access logs, AI assistant, users and roles, taxes, export contract (project primary)
• Open Mercato, SPEC-024 financial module specification, status "Specification" (project primary)
• Open Mercato, certified partner directory, 27 agencies listed (project primary, checked 3 September 2026)
• Package registry listings for the Open Mercato ecosystem, including integration-ksef-direct from Fast White Cat, the Dainamite CPQ and billing engines, and the Northbound data-sync adapters (registry primary, checked 8 September 2026)