ERP for public institutions and faculties should connect financial accounting, inventory and materials operations, operational records, and reporting so that the same business event is not manually re-entered across multiple records. The aim is not merely to combine applications, but to establish a clear flow: who initiates a purchase, who approves an expense, when a liability arises, how receipt is recorded, and how data is prepared for reporting and management decisions.
Within institutions, processes often develop by department. Finance maintains general ledgers and liabilities, procurement tracks requests and purchase orders, the warehouse records receipt and issue of materials, while departments, services, or projects maintain their own working lists. This division of work is understandable, but without well-defined links it creates duplicate entry, inconsistent codes, late postings, and demanding reconciliation at the end of a period.
When selecting ERP for faculties or other institutions, functional modules are often listed first. It is more useful to start with the events that move through the institution: a purchase request, approval, purchase order, goods receipt, invoice, payment, issue from inventory, cost allocation, or report preparation.
Each event should have:
Once these links are defined, ERP can become a shared operational workspace. When they are not, even a technically integrated system may simply transfer inconsistent data more quickly.
Institutional accounting cannot remain separate from operational work if financial reports are expected to reflect actual liabilities, receipt of goods, material consumption, and the activities of organisational units. Financial accounting should receive data from earlier steps, with clearly defined controls before posting.
In practice, it is important to agree on answers to questions such as:
The answers do not need to be identical in every institution. What matters is that they are visible in the process, understood by users, and supported by authorisation rules. This reduces the need for accounting staff to seek context later through email, paper files, or separate spreadsheets.
Inventory and materials operations matter where an institution purchases, receives, stores, and issues materials, small inventory items, or other goods that need operational tracking. At a faculty, this may include laboratory consumables, office supplies, teaching equipment, or materials for specific activities. The scope and level of detail depend on how the institution actually works.
A connected process commonly starts with a user request, continues through approval and procurement, and then covers receipt, recording of location or assignment, and issue. The financial effect and the operational trail do not have to arise at the same time, but they need to be understandable in relation to one another.
Useful decisions before system configuration include:
Without these decisions, the item master quickly becomes a collection of inconsistent names, and inventory loses operational value. Conversely, excessively detailed tracking can burden users and create more administration than benefit. The level of control should match the risk, value, and frequency of each type of purchase.
An operational record does not necessarily mean a separate large system. It can be a structured set of data about requests, contracts, projects, laboratory activities, premises, equipment, or other objects that matter to an institution's work. The key point is that data should not be kept only as free text when it later needs to connect to a financial or inventory document.
For example, a purchase request may contain an organisational unit, the purpose of purchase, the person requesting the material, the planned activity, and a funding source. This data does not replace accounting processing, but it gives accounting a basis for more accurate classification and review.
For ERP for public institutions, it is particularly useful to distinguish data used for everyday work from data used for reporting. Some data may serve both purposes, but each field should have an owner, a definition, and an entry rule. If no one is responsible for the quality of organisational unit, project, or funding source master data, reports will eventually require manual corrections.
A report does not solve inconsistent source data. Before creating new views, it is therefore necessary to determine which transactions feed a report, which point of recording is authoritative, and who confirms the data.
An institution may need views of liabilities, spending by organisational unit, open purchase orders, inventory balances, costs by activity or project code, and variances against internal planning. This does not mean that all users should see all data. Roles, access levels, and confirmation rules are part of process design.
It is useful to distinguish three types of reporting:
The same figure may appear in multiple views, but its meaning must remain consistent. For example, ordered value, received value, recorded liability, and paid amount are not the same category, and a report should not present them as if they were.
Consider a faculty where a laboratory submits a request for consumable materials. A manager or another authorised person confirms the need, procurement manages the procedure according to the institution's internal way of working, and after delivery a responsible person confirms receipt. The warehouse or laboratory records the quantity and the place where the material is held or consumed. Accounting then processes the invoice using document data that provides business context.
A connected ERP process does not mean that one person performs all steps. On the contrary, it separates roles while retaining the connection between request, purchase order, receipt, invoice, and issue. This makes it possible to determine where an item stands in the process without collecting the information again from several sources.
Before implementing or changing a system, it is useful to mark, for this example:
Connecting processes is not only a technical project. A change to master data, authorisations, or work sequence affects people who enter and confirm documents every day. It is therefore not reasonable to assume that all existing practices can be replicated without adjustment.
Several trade-offs occur frequently:
This process perspective is also not a substitute for legal, tax, or regulatory review. Each institution should separately verify obligations related to its status, funding sources, internal policies, and regulations that apply to it.
Before selecting or extending ERP, an institution can benefit from reviewing one to three processes with the highest number of manual transfers: for example, purchase-to-invoice, receipt and issue of materials, or preparation of periodic reports. For each process, it should list documents, roles, master data, approvals, data transfers, and the most common exceptions.
ORKA can help structure this initial review through ERP and process screening , while questions about the organisation of accounting processes can also be connected to Accounting services . The outcome is not a pre-set solution, but a clearer basis for deciding which processes to connect, in what order, and with what level of control.