askcust develops custom ERP systems for agroholdings: several legal entities and clusters in one system with shared master data, consolidated reporting and access control. For holdings where each company keeps its records in its own accounting database and the management summary is assembled by hand.
ERP development for agroholdings is building a system that brings the management accounting of several legal entities and clusters into one environment: shared master data for crops, fields, inventory and counterparties, consolidated costs and reporting, and roles limited to their own company. It differs from an ERP for a single agricultural enterprise by the multi-level structure of holding, cluster, legal entity and division, and by consolidation that eliminates intra-group transactions.
Data from the legal entities flows into a shared model automatically, intra-group sales and services are eliminated by rules, and costs and results per cluster are available in shared reports, without spreadsheets the finance team assembles at the end of each period.
Crops, fields, inventory, cost items, norms and counterparties are kept in shared master data with change rules. Cluster indicators become comparable: a hectare of wheat in one cluster is costed the same way as in another.
A legal entity is connected from a template: master data, roles, exchange with its accounting database and telematics. A new company joins the consolidation through a proven procedure instead of a separate project each time.
Roles limit access by legal entity and cluster, requests and payments follow the holding's approval routes, and the audit log shows who changed what and when. Everyone sees their own company, and management sees the whole holding.
Migration goes cluster by cluster: the system first runs in parallel with the existing records, each cluster switches over between seasons, and the local accounting system keeps the statutory and tax books of the legal entities as before.
The set and order of modules are defined during the assessment; the pilot is one cluster.
Holding, clusters, legal entities, divisions and warehouses as a hierarchy; every document and indicator belongs to its level, and reports can be built at any of them.
Centralised reference data for crops, fields, inventory, machinery, cost items and counterparties; changes go through a request and approval, with duplicate checks and distribution to the entities' databases.
Costs per crop, field and cluster, allocation of overheads, elimination of intra-group transactions, and management reporting for the holding on shared data for any period.
Season budgets for clusters and companies, plan versus actual by cost item and field, and limit control when purchase requests are approved.
Rights limited by legal entity and cluster, approval routes for requests and payments, and a change log for internal audit and the holding's security team.
Exchange with the accounting system of each legal entity, e-reporting, telematics, elevator weighing software and bank statements through one layer with queues, retries and error control.
Sown areas, progress of field operations, grain and inventory stocks, costs and receivables across the holding, with drill-down to a cluster, company and field.
Existing systems of the legal entities are not replaced overnight: the ERP exchanges data with them until a cluster has fully switched over.
| criterion | Standard ERP | Custom ERP by askcust |
|---|---|---|
| Accounting core | Proven bookkeeping and tax accounting out of the box. | Bookkeeping stays in each entity's accounting system; the ERP covers management accounting and consolidation. |
| Agricultural specifics | Fields, crop plans, in-kind payments and seasonality through industry modules or customisation. | Fields, seasons, crop plans and in-kind payments are part of the data model from the start. |
| Holding structure | Several organisations in one database; non-standard clusters within the product's limits. | A holding, cluster, legal entity and division hierarchy that mirrors your real structure. |
| Rollout | Usually means moving all legal entities to a new accounting platform. | Cluster by cluster, in parallel with existing systems, switching over between seasons. |
| Cost of ownership | Licences per user and module, with customisation by a partner integrator. | One-time development of stages and support by agreement; no per-user licences. |
| When to choose | The holding is ready to move to one accounting platform and standard processes. | Mixed systems across entities, agricultural processes, consolidation without stopping the season. |
The structure of legal entities and clusters, existing systems, master data, management reports and the real data flows between them. The result is a systems map and a stage plan with a pilot cluster.
Agreeing the master data structure, consolidation rules and roles with the finance team; a prototype of the key management reports with examples from real data, before development starts.
Deployment for one cluster in parallel with the existing records, exchange with its accounting databases and telematics, and reconciliation of the results with the finance team.
Connecting the remaining legal entities from the proven template, switching each cluster over between seasons, and training key users in every cluster on their own data.
Support, new reports and modules, connecting new farms as the holding grows, and integration updates when accounting systems and services change.
examples of askcust's work →not agriculture, but the same kind of task: records, CRM, automation
Yes, and that is the recommended path. The system first runs for one pilot cluster in parallel with the existing records, the results are reconciled with the finance team, and only then does the cluster switch to the ERP; the rest follow the same template. The switch is planned between seasons so that the system does not change in the middle of sowing or harvest.
The local accounting system, BAS in Ukraine, remains the bookkeeping and tax system of each legal entity. The ERP exchanges master data, documents and balances with it through the integration layer: management accounting, consolidation and agricultural processes live in the ERP, while statutory reporting stays in the accounting system. The holding does not have to replace bookkeeping in all companies at once.
It depends on the number of legal entities, clusters and systems to integrate, so the timeline is set after the assessment. The rollout goes in stages: shared master data, a pilot cluster, then the remaining clusters from the template. The holding gets the first result, consolidated reports for the pilot, after the pilot stage rather than at the end of the whole project.
The cost is defined by the number of modules, legal entities and integrations and by the amount of master data and history to migrate, not by the number of users. After the assessment askcust estimates the first stage, shared master data and a pilot cluster, with a fixed scope agreed in writing; further stages are estimated separately, taking the pilot results into account.
Yes. Telematics such as Wialon, elevator weighing software and bank statements are connected through the integration layer as data sources, without being replaced. Their data flows into consolidated reports: actual field operations into field costs, grain intake and shipments into cluster stocks. If a cluster uses different telematics, a separate adapter is added for it.
The holding. The code is handed over to the client's repository, the system runs on the holding's servers or in its cloud account, and askcust's access is limited to development and support. It is also a question of independence: the ERP can be developed further with askcust, an in-house IT team or another contractor. Documentation on the architecture, integrations and deployment is handed over together with the code.
A reply within one business day; a call only if we agree on one.