Commerce Weavers is taking responsibility for building the Open Mercato financial module. The first iteration covers the chart of accounts and general ledger. We're starting with these because the accounting areas that follow need a common place to record financial data. In this article, we explain why we chose this order, how the new foundation is intended to work with existing modules and what else is included in the planned scope. This is the first part of a series on the Open Mercato financial module – in the following parts, we'll report on progress in the next areas.
Open Mercato already records events that take place within a company, such as sales, issuing invoices, shipping and receiving goods into a warehouse. What it does not yet have is a common place where the financial impact of these events can be recorded in the accounts.
Today, teams implementing Open Mercato handle accounting requirements on their own. They either build the functionality they need or store the data in a separate accounting system and integrate the two. Such implementations already exist and work. By creating a shared financial module in the open-source core of Open Mercato, we want to ensure that future users do not have to design the same foundation from scratch every time.
This reflects one of the principles behind Open Mercato: the platform provides around 80% of the functionality that companies have in common, while the remaining 20% can be built to meet the needs of a specific organization. These proportions describe the development approach rather than a fixed scope for every implementation. Accounting is one of those common needs, which is why we're adding its foundations to the part developed at the Open Mercato level.
Thinking about implementing Open Mercato? See how we can help → Open Mercato Implementation – custom CRM & ERP without per-seat licensing.
The first iteration of the Open Mercato financial module covers two elements: the chart of accounts and the general ledger. These are intended to provide the foundation for subsequent accounting features.
A chart of accounts is an organized, numbered list used to record all of a company's business transactions. It has a hierarchical structure, from general ledger accounts (for example, "Cash in Transit") to more detailed accounts beneath them, such as subaccounts for individual payment gateways like Stripe or Tpay.
A company will typically start with a standard chart of accounts and adapt it to its business. Its structure also determines how data is grouped in financial reports. A default chart of accounts created in collaboration with incro will also be part of our contribution.
The general ledger is the central record of all accounting entries. It is based on the principle of double-entry bookkeeping: every transaction must balance, meaning that the total amount on one side (debit) must always equal the total on the other side (credit), even when a single entry involves multiple accounts.
There is also a fundamental principle of immutability in accounting. For developers, think of it as a classic append-only database. Once a transaction has been posted, it cannot simply be overwritten or deleted. To maintain a complete audit trail, errors are corrected through a separate entry. This is why the Open Mercato financial module backlog includes support for reversing entries, providing a system mechanism for making such corrections.
There are three reasons behind this order. The first is the need for a common way to record financial data. The second relates to functionality that Open Mercato already has. The third involves the existing Polish module, which needs to be taken into account when designing the new foundation.
Sales and purchase invoices, bank statements, depreciation, revenue recognition over time and tax calculations all involve transactions that need to be recorded in the accounts. The general ledger provides a common place for financial entries originating from different areas.
If we built these features before the general ledger, each one would have to solve the problem of recording financial data independently. Those separate solutions would then need to be connected later. That is why we're starting with a foundation on which further work can be built.
This does not mean that connections to all business processes will be created immediately. The current backlog defines the scope of the planned features and integrations.
Open Mercato already supports sales invoicing and advanced inventory management. We do not need to build these features again. What we do need is a shared ledger to which the accounting entries resulting from these operations can be posted.
Posting sales invoices is planned as a separate area in the backlog. Sales invoice issuance already works, but posting those invoices to the appropriate accounts is still ahead of us.
The situation is different for warehouse documents. Although Open Mercato already handles warehouse processes well, automatically posting these documents is not included in our current financial module backlog. If this integration is important to you now, we'd be very happy to hear from you and collaborate on developing this area.
Open Mercato already has a working Polish finance module, although it currently operates independently of the general ledger we're building. It successfully sends invoices to KSeF, receives purchase invoices, and generates and submits JPK files. It does not need the new financial module to perform these tasks.
Because the platform does not yet have a dedicated purchasing module, the Polish module maintains its own purchase records. In the codebase, it currently serves as the temporary source of truth for this area. This is a deliberate solution that allows existing processes to operate.
Building the general ledger, however, means that two areas will need to be connected: the existing records in the Polish module and the new accounting entries. We do not want to maintain two independent places for storing the same financial information. Ultimately, the Polish module and the general ledger are intended to form an integrated mechanism.
This is also why the contracts between modules need to take the platform's current state into account. The original plan assumed that the Polish layer would be built on top of ready-made contracts provided by the financial core. In practice, the order turned out differently: the Polish module was created first and already has its own tables, migrations and working processes.
We are therefore not designing the contracts from scratch in isolation from the existing solution. We need to account for what already works, as well as maintain backward compatibility with existing data and implementations.
These are not merely theoretical assumptions. The backlog includes tasks for declaring the Polish module's dependency on the general ledger, exposing a shared tax contract and moving purchase records to accounting entries. These are planned tasks, not features that are already available.
We don't want to build additional accounting features as separate solutions that will only need to be connected later. We're starting with the chart of accounts and general ledger to establish a common set of rules for recording financial data. At the same time, we're designing this foundation around what already works in Open Mercato, particularly the Polish module. This will allow us to develop accounting as a coherent part of the platform.
The chart of accounts and general ledger are the first iteration, not a complete accounting module. The backlog also includes further elements of the foundation: handling documents and business transactions, reporting, accruals and deferrals, and the automation of accounting entries.
The scope below reflects the state of the backlog as of September 21, 2026. We have divided it into three thematic groups to show the dependencies between different areas. This is not a detailed roadmap, nor does it mean that all features within a given group will be delivered at the same time.
This group covers the core of the system: the general ledger engine and default chart of accounts. The backlog also includes accounting entries, reversing entries, accounting periods together with closing and reopening them, analytical dimensions on entry lines, and account balances.
A trial balance is also planned. It provides a summary of account movements and balances and is used to verify general ledger data. It should not be confused with the balance sheet that forms part of the annual financial statements.
The backlog also includes a bulk ledger read service for other modules and an audit export.
Further work includes a business partner registry with verification against GUS, VIES and the Polish VAT whitelist, together with an approval process. Purchase invoice handling, including approval, is also planned, as is the posting of sales invoices, which can already be issued in Open Mercato.
The backlog also covers payments for purchase invoices and payment batches, as well as bank statement handling and reconciliation with outstanding receivables and payables. Fixed assets are a separate area, including depreciation, impairment and disposal. It is worth emphasizing that depreciation is an integral part of fixed asset accounting rather than simply an automation mechanism.
Each of these areas has its own separate scope of work. This does not mean that all of the processes listed above will be available with the first iteration of the chart of accounts and general ledger.
The backlog also includes the generation of annual financial statements covering the balance sheet and profit and loss statement (P&L) in both formats used in Polish accounting: the function-of-expense method and the nature-of-expense method. JPK for accounting books (JPK_KR_PD) is also planned, along with a shared tax contract connecting the Polish layer.
It is important to note that JPK_KR_PD is a planned feature and should not be confused with support for JPK_V7 records, which already works in the Polish module.
The further scope includes multi-currency support and balance sheet valuation, accruals and deferrals, as well as an accounting rules engine incorporating account 490 and cost centers (MPK). The rules are intended to automate the posting of recurring transactions. Where no automation is available, the system will of course allow an accountant to post entries manually.
We started the work with a full-day Event Storming workshop held in Katowice on September 5, 2026. The workshop was facilitated by Mariusz Gil, with Mateusz Duda from incro, a financial controller and former accountant, acting as the domain expert. The development team and the Open Mercato core team also took part.
A big thank you to the Iteo team as well for providing the office and for their hospitality.
The first iteration covers the chart of accounts and general ledger, rather than full accounting functionality. The remaining features described in this article are included in the backlog and will be introduced over time.
We would like to release the first iteration around the end of October or beginning of November. Until then, each implementation needs to handle accounting in Open Mercato on its own.
| Area | Status |
|---|---|
| Sales invoicing | available |
| Warehouse processes | available |
| KSeF and JPK_V7 (Polish module) | available |
| Chart of accounts and general ledger | first iteration – end of October or beginning of November 2026 |
| Posting of sales and purchase invoices | in the backlog |
| Trial balance, accounting periods, reversing entries | in the backlog |
| Financial statements, JPK_KR_PD | in the backlog |
| Posting of warehouse documents | outside the current backlog |
State of the backlog as of September 21, 2026.
Commerce Weavers is responsible for building the Open Mercato financial module. The first iteration covers the chart of accounts and general ledger.
No. Open Mercato already supports sales and warehouse processes, while the Polish finance module handles tasks related to KSeF and JPK. A shared general ledger is part of the financial module currently being developed.
Until the financial module is available, each implementation handles accounting on its own. Teams either build the functionality they need or integrate Open Mercato with a separate accounting system. The first iteration of the module, covering the chart of accounts and general ledger, is planned for the end of October or beginning of November 2026.
Posting sales invoices is included in the backlog as a separate area of work. Sales invoice issuance itself already works in Open Mercato.
It is not currently included in the financial module backlog. Although Open Mercato supports warehouse processes, the automatic posting of these documents is not part of the work described here.
We plan to release the first iteration, covering the chart of accounts and general ledger, around the end of October or beginning of November 2026. Further features from the backlog will be introduced gradually.
Yes. The Polish finance module sends invoices to KSeF, receives purchase invoices, and generates and submits JPK_V7 files. It works independently of the general ledger currently being developed. JPK for accounting books (JPK_KR_PD) is still in the planning stage.
Choosing a framework may seem like a purely technical decision. In practice, however, it affects much more than how deve...
Read more →
AI is becoming an increasingly important part of the day-to-day work of e-commerce development teams. It helps generate ...
Read more →
Deciding to migrate to Sylius 2 is only the beginning. In practice, the success of the upgrade depends much more on prep...
Read more →
