Skip to main content
Case study: accounting workflow automation

HUB.ITM.PL: invoice data prepared for import instead of manual re-entry

An accounting office received invoices from different applications and files. We built a system that read the data and prepared EDI++ for Subiekt GT and Subiekt nexo.
Illustration of data from different files being mapped and checked before becoming a structured package for the target system.

A conceptual data-conversion workflow prepared with synthetic data. It is not a screenshot of the historical HUB.ITM.PL system.

Starting point: thousands of invoices from different sources

The project was created around 2018 for a large accounting office. The company received documents from many clients, but the data did not arrive in one ready-to-use format. Its sources included Comarch ERP Optima, Sage Symfonia ERP, JPK-FA, UBER data, and XML, XLS and CSV files.

Each source used its own field layout and way of recording information. The office staff therefore had to re-enter data from thousands of invoices into the applications they worked with. As the number of clients grew, the same repetitive work took more time.

One basic importer was not enough

The file format was only part of the problem. The same information could be stored in different columns, use different names or require transformation before an output file could be created. Importing the source file without mapping its data would not solve the full process.

The office did not want to replace the applications used by its clients either. It needed a layer between the different sources and the target system. That layer had to read the data, organise it according to shared rules and create a file accepted by Subiekt.

How data preparation worked

We divided the process into repeatable steps:

  1. The system read data from a supported application or file.
  2. Source fields were assigned to the correct target fields.
  3. The data was checked before the output was generated.
  4. The system prepared an EDI++ file intended for import into Subiekt GT or Subiekt nexo.

The system's role ended with preparing the EDI++ file in the required structure. It did not replace the Subiekt applications.

Result: a repeatable process instead of manual re-entry

The office no longer had to transfer the data from every invoice by hand. It could process subsequent files according to an established workflow and receive an output ready for import.

This automation increased the office's operational capacity. The company could support more clients without increasing manual document re-entry at the same rate.

Why we describe this as a historical project

HUB.ITM.PL is no longer in use. Data exchange formats changed over time and became more standardised. We therefore do not present the old application as compatible with current versions of the systems named in this case study.

The project still demonstrates an important approach to automation. When a company uses several tools, replacing the entire system is not always necessary. An importer or integration layer that organises data between the source and target application can sometimes be the right answer.

When similar automation makes sense

A ready-made importer may be sufficient when data comes from one stable source, follows a compatible structure and is moved only occasionally. A custom solution is worth considering when:

  • files or data regularly come from several systems;
  • their structure does not meet the target application's requirements;
  • employees repeatedly enter the same types of information;
  • mapping, transformation or validation of required fields is needed before import;
  • the company wants to keep its existing systems while improving data exchange between them.

The recurring business problem matters more than the name of the format. We first establish where the data originates, where it needs to go and which decisions must remain with an employee.

What to establish before building an importer

Before starting a similar project, we need to know:

  • which system or file type contains the source data;
  • which application should receive it and what format that application accepts;
  • how often the transfer takes place and how many documents it covers;
  • which fields need to be combined, changed or completed;
  • how errors are checked now and who approves the data before import.

You do not need to send real invoices or client data at the first stage. A process description and a sample file structure with confidential details removed are enough. This allows us to assess whether you need a custom integration, a smaller importer or a simpler change to the workflow.

Want to reduce manual data entry?

Tell us where the data comes from, which system should receive it, how often the work is performed and how you check the result. We will use this information to recommend a safe first step.

Talk to us about data imports

See also system integrations and APIs, custom CRM and ERP systems and our other projects.