For management, this meant there was no single consolidated view of the group. To obtain a P&L report or reconcile figures across locations, data had to be exported manually from several systems and consolidated in spreadsheets. As the network grew and expanded geographically, this approach became increasingly difficult to manage.
Management accounting • P&L reporting • Consignment
Implementation of a central management accounting database aggregating data from different locations
For a company with its own manufacturing operations and B2B/B2C sales across several countries, the CBPM Service team designed a central Business Central MAIN database for group management accounting. Its purpose is to aggregate data from local operational databases and external systems, support cross-border scenarios, including consignment, and provide P&L reporting across the entire network.
📑 MAIN database
The MAIN database architecture was designed as a single center for the group’s management accounting
📉 API-based data exchange
API-based integrations were built with local databases, BAF/1C, Magento, and other data sources
🕐 Consignment scenarios implemented
Consignment scenarios between Spain and the Netherlands were implemented with automatic document generation
Situation before the project: data across multiple systems with no consolidation
Sales, expense, and intercompany settlement data were distributed across several incompatible systems. Generating a reliable network-wide P&L in real time without manual consolidation was impossible.
Cross-border consignment transactions and exchanges between local databases and external systems had no unified control environment. Any discrepancies in the data were discovered only during manual reconciliation and with a delay.
The group’s infrastructure included local databases in Spain, Ukraine, the Netherlands, and Poland, BAF/1C Manufacturing, Magento, SAGE, and regulatory systems. Building an up-to-date management view from such a large number of sources without a systematic solution was structurally impossible.
Request and critical requirements
The client requested the development of a central management accounting environment that aggregates data from the group’s operational systems and provides a unified analytical view. The MAIN database had to remain separate from local fiscal environments and avoid duplicating them, serving only to receive data and transform it into management reporting.
1. Centralized MAIN database for management accounting
A key requirement was to implement the MAIN database as a unified management accounting environment for consolidating data from local databases and external systems without duplicating local fiscal environments.
2. API-based data exchange with all data sources
The system had to ensure stable API-based retrieval of key entities, including Items, Locations, Customers, Orders, and Dimensions, from local databases and external systems without compromising data integrity.
3. Consignment scenarios and P&L reporting
The MAIN database had to support cross-border consignment operations and generate P&L reporting as a tool for monitoring financial performance across the entire network.
4. Logging and data exchange quality control
A critical requirement was to minimize the risk of incorrect matching of products, serial numbers, and customers between databases. Every data exchange had to be logged with a status and the ability to trace discrepancies.
5. Integration with the existing ecosystem
The MAIN database had to connect to local Business Central databases, BAF/1C Manufacturing, Magento, and SAGE without disrupting their operational processes. Particular attention was given to accurate master data mapping across all databases.
6. Separation of management and regulatory accounting
The MAIN database was not intended to replace local fiscal environments. For scenarios between Spain and the Netherlands, VAT, reverse charge, ESL reporting, and Intrastat had to remain correctly reflected in the relevant local databases.
What the CBPM Service team did and how
Approach
The approach was based on a clear separation of responsibilities: local databases remained the operational and fiscal environments for each country, while the MAIN database served as the management center, receiving data from them via APIs and transforming it into a unified analytical view. This made it possible to preserve local regulatory accounting while consolidating data across the entire group without manual reconciliation.
MAIN database architecture
The solution was built around a separate Business Central MAIN database for the group’s management accounting. Data is received via APIs from local databases and external systems, including Items, Locations, Customers, Orders, and Dimensions. Registers of transmitted documents, an Exchange Log List, and master data mapping between databases were implemented to provide control over the status of every exchange and identify discrepancies before they affect reporting.
Consignment scenarios within the management accounting environment
Consignment operations between EU countries required dedicated logic at the MAIN database level. Goods are physically transferred to the receiving country, but ownership changes only when the item is sold to the end customer. This requires different documents to be created in the local databases and in the MAIN database.
A scenario was implemented in which the MAIN database receives information about a Posted Statement and automatically transforms it into a posted sales invoice from the receiving country’s consignment warehouse, with reconciliation between databases.
Standard functionality and customization
Standard Business Central functionality
Used as the foundation for management accounting entities and documents.
Customization focused on areas where standard functionality did not cover the requirements
Custom API-based data exchanges between databases, consignment logic, new tables for master data mapping, data exchange logs, and serial number and weight fields in the relevant documents.
Separation of environments as an architectural principle
Separating the MAIN database from local fiscal databases is not merely a technical decision, but an architectural principle. Local databases retain full operational and regulatory independence, including VAT, ESL, and Intrastat requirements. The MAIN database receives only management data from them without interfering with the fiscal accounting of individual locations.
Implementation and collaboration with the client’s team
The work was carried out in stages: first, the architecture of the MAIN and local databases was designed and the integration environments were defined; then master data mapping, API-based exchanges, consignment scenarios, and P&L reporting were implemented; finally, reconciliation between databases was tested.
One of the key factors in successfully completing the project within the four-month timeframe was the client’s appointment of a responsible project manager with decision-making authority, while a top executive joined as project sponsor and participated in monthly coordination meetings. This made it possible to maintain efficient communication, resolve issues in a timely manner, and control task execution without delays or the need for escalation.
Foundation for management transparency
The CBPM Service team built an architecture that addresses the original consolidation challenges while creating a foundation for future scaling: new locations and data sources can be connected without rebuilding the central environment.
A unified environment was established to collect management data from all operational sources without manual consolidation in spreadsheets.
Cross-border consignment operations are reflected in management accounting automatically, with the correct distribution of documents between local databases and the MAIN database.
Every exchange between databases is recorded with a status, while discrepancies are detected systematically rather than during the next manual reconciliation.
A foundation was established for P&L reporting and inter-database reconciliation across the entire network.
