The system has been running at the client since September 2026 and is still being developed. We describe what is already deployed and in use, and at the end we list plainly what is still being built. We do not disclose the client's business data: amounts, construction site names or personal names.
Formwork rental calculated in Excel
ABC Szalunki is a rental company for wall and slab formwork systems: four branches, three legal entities, their own warehouses and equipment sub-hired from outside suppliers. Equipment goes out to construction sites, comes back in parts, sometimes damaged, and every month has to be settled to the last grosz (one hundredth of a zloty).
Goods issue and goods receipt notes were created in Comotel, a Polish desktop warehouse management program. The rental settlement, however, happened outside it: every line of every document was retyped by hand into an Excel spreadsheet, which calculated the monthly statement and served as an attachment to the invoice. The total from the spreadsheet was then retyped once more, into the accounting software.
Rental looks like simple multiplication: rate times days times quantity. In practice returns are often partial, additional deliveries land in the middle of a period, the end of the month cuts the charge in two, and discounts work on two levels and can be withdrawn when a customer stops paying. Each of these points was a source of mistakes when retyping, and the client named adding transport and extra services as the most common reason for corrections.
The formula first, code second
The enquiry from ABC Szalunki came in through the form on our website. The same day the client received 55 questions in ten areas: the current process, Comotel, documents, charging rules, inspection reports, statistics, users, data volumes. Answers to all of them came back the next day, together with spreadsheets, document templates and an online meeting at which the client walked us through the settlement spreadsheet live.
Before the first line of code was written, we reconstructed the calculation formula from the client's spreadsheet and checked it by hand on a real statement. Every line, the discount, transport, the daily rental cost, weight and running metres matched to the grosz. The client's reply was short: "the piece-day calculation is correct". On top of that they received project documentation with the charging rules, use cases and acceptance criteria, and a clickable mockup of the system.
A statement from the system has to match the client's manual settlement to the grosz. Not "roughly", not "after rounding". That one sentence set the direction for the whole project: every charging rule has a source in the spreadsheet or in a client answer, and every change to the calculation goes through a fresh recalculation of the reference data.
From first contact to signing the contract, the NDA and the statement of work took four days. Work started on the day of signing.
The charging engine
At the heart of the system is an engine that calculates rental according to the client's rules. The documentation now describes 31 business rules, each with its source identified. The most important of them:
- Calendar days, counting both the day of issue and the day of return
- Partial returns and additional deliveries during the period, each operation with its own day count, with no limit on operations per statement
- A cut at the month boundary and an opening balance carried over to the next period
- Group and general discounts, the prompt payment discount withdrawn separately when closing the month, and the amount of lost discounts in the statistics
- A minimum charging period and a top-up to the logistics minimum when a site is closed
- Shortages settled with an internal issue note at the customer's cost, transport priced after the fact, an inspection report with cleaning and repair costs
- Consumable parts and accessories as sales on a separate invoice, outside the rent and discounts
The engine recalculated three further site workbooks supplied by the client, straight from the files, with the chain of opening balances between months. Together with the January trial that makes 17 months across 4 sites matching to the grosz. We separately checked the situations where spreadsheets tend to be unreliable: a leap year, the switch to summer time and summing a hundred lines of one grosz each.
In the questionnaire answers the minimum charging period was 7 days, and that is how it went into the first version of the rule. While analysing the quotation template in the client's spreadsheet we found the entry "8 days, every issue from the warehouse". We corrected the documentation, the user manual and the code, and added one rule to the project principles: when it comes to charging, the client's source document wins over an answer given from memory.
Data from Comotel, to the grosz
The system was to start with the full history of the year, not with an empty register. Without access to the Comotel database, the data arrived as reports exported from the program: all documents and opening balances since 1 January. We wrote a parser for these reports and compared the result with Comotel's own control totals.
Two traps only surfaced in the data. The "Price" field in Comotel is the deposit value, not the rental rate, so charging from it would have produced amounts contradicting the contracts. The movement report also does not include the warehouse, which made some sites started the previous year show negative stock. We described both cases to the client as questions with concrete examples instead of guessing. The "Recalculate period" button builds each site's whole chain of statements from its first document. That produced more than one and a half thousand statements for several hundred sites, from January onwards.
From statements to a system that runs the company
The contract covered statements, inspection reports and statistics. After the presentation the client saw that the same approach could replace further spreadsheets and programs, and ordered the next modules in stages, paying upfront. Each stage followed the same path: a description in the documentation, deployment, a walkthrough on a copy of the client's data, fixes.
Analysis and mockup
55 questions, the formula reconstructed from the spreadsheet, project documentation with rules and use cases, a clickable mockup. All before the contract was signed
Settlements, quality, statistics
Spreadsheet import, issue and receipt notes entered from the keyboard, statements printed on a single A4 page, handling costs, inspection reports, closing periods and corrections, three entities with their own footers
A full year from Comotel
Documents and opening balances since January loaded and verified, statements built retroactively for all sites
Warehouse and transport
Warehouse stock calculated from documents, transfers, servicing, stocktaking, sub-hire from third-party warehouses, the JPK_MAG file (the Polish tax authority's standard audit file for warehouse records). A log of transport runs with carriers, drivers and statistics as in the client's spreadsheet
Quotations with signature
A quotation board with versions, sending from the client's own mailbox, a quotation page for the customer with an SMS code and signature, a contract and a site created from the accepted quotation
Move to the client's server
Migration from our cloud to a server purchased on the client's account, with record counts compared before and after
Framework agreements, briefs, site map
Framework agreements in a separate workflow with a template loaded from a Word file, an estimate quotation based on rotations, a form builder for customers, distances from the map, a product card with rate history
Quotations and signatures without an outside subscription
The client wanted a quotation to reach the customer, come back signed and immediately create a contract and a site with the rates from the quotation. Instead of an outside e-signature platform we proposed an in-house workflow: the customer receives a link, reviews and completes their details, confirms with an SMS code and signs. The system stores the evidence with a timestamp, a snapshot of the content and a PDF with a system seal.
- Three types of quotation: detailed, simplified and an estimate based on equipment set rotations, with a cost tolerance
- Versions, rejection with a reason, reminders, acceptance outside the system with a scan
- Protection against a race condition: a change to a quotation at the moment the customer is signing it will not go unnoticed
- A brief builder: the company assembles a form for its customers itself, and a submission creates a draft quotation
- Framework agreements signed outside the system, by hand, with a qualified electronic signature or the Polish government e-ID, and registered with a scan, because that is how the client works
The scale of the system
What started as a statement generator is today the system ABC Szalunki uses to run the whole cycle, from a quotation request, through equipment issue, transport, return and inspection report, to the statement, statistics and warehouse reporting.
- Modules: customer and site records, goods issue, goods receipt, internal issue and internal receipt notes, a document buffer, statements, inspection reports, a price list with rate history, warehouse, transport, quotations, framework agreements, briefs, statistics, notes, roles and permissions
- Twelve document types with daily numbering by warehouse code
- Four built-in roles and custom roles built from 21 permissions
- A change log at database level: every change to an amount, a rate or a document has an author and a trail
- A settlement trail: for every amount on a statement you can see which documents and days it comes from
Integrations
- Comotel: loading documents, opening balances and warehouse stock from the program's reports
- Excel: importing the client's workbooks, including ones with macros, the catalogue, the price list, the carrier database and transport runs; export of every list and a full data backup to a file
- The Polish Ministry of Finance VAT taxpayer register: company name, REGON (statistical number) and KRS (the Polish company register) number from the NIP (tax ID)
- SMSAPI (a Polish SMS gateway): codes confirming the signature of a quotation
- The client's mail: quotations and notifications sent from their own mailbox
- OpenStreetMap: site locations, a map and route distances for each transport run, with no paid key
- JPK_MAG: the file for the tax office generated from warehouse documents
- PDF printouts generated on the server: statements, documents, inspection reports, quotations and contracts
Working on the client's data, not on examples
Since the first deployment the client has been working on the live system, so every change follows the same procedure: a database backup before deployment, a trial migration on a copy of the client's data, a comparison of the number of statements and their totals before and after, and only then production. After every larger deployment the code goes through three independent reviews: security, calculation correctness and conformity with what was ordered.
The top-up to the minimum charging period matched to the grosz on four reference sites. Only a recalculation on a copy of the full data showed that the rule would have reached back to more than twenty returns loaded from Comotel and charged customers amounts nobody had ever billed them. The rule went live only for documents issued in the system, from an agreed date, and the decision about the past went back to the client as a question. Since then we check every new calculation rule on a copy of the full data.
The reviews also caught bugs nobody had reported. The last day of the month, calculated from the local date, fell a day earlier during summer time, so a document dated 31 May fell outside the period. The search did not ignore Polish diacritics, so typing "dzw" did not find "dźwigary" (girders). A return dated before the issue produced negative rent. All of it fixed, each with a test that makes sure it does not come back.
A document is created in Comotel, then retyped into Excel
The spreadsheet fits 13 operations per statement
A one-page printout only after hiding rows by hand
Transport and services added from memory, the most common reason for corrections
The total retyped once more into the accounting software
Settlements for all branches in the hands of one person
Quotations in separate files, signatures on paper
Documents issued in the system from the keyboard, no mouse needed
No limit on operations, verified on a statement with 21 operations
A statement on a single A4 page, PDF in 1.3 seconds on the server
A checklist blocks closing the month when a transport has no amount
The statement total ready for invoicing, a link to accounting planned
Roles, permissions and a change log for the whole team
A quotation signed with an SMS code creates the contract and the site
Documentation that grows with the system
After every deployment the client receives three documents in a new version. The project documentation contains the rules, use cases and a register of open questions with their resolutions. The user manual now runs to more than a hundred pages. The calculation compliance check has reached its thirty-second version and documents every change to the charging logic with a worked calculation. On top of that come recordings of key operations and monthly work reports.
Every piece of feedback from the client, whether sent as lists in Word files, by email or as handwritten notes on printouts, gets a number, a cause and a status. Between the presentation and the beginning of October we implemented seven such lists.
Technology
React 19
TypeScript
PostgreSQL 17
Drizzle ORM
Tailwind CSS 4
Zod
decimal.js
ExcelJS
Playwright
Vitest
Leaflet and OpenStreetMap
SMSAPI
JPK_MAG
Docker
Coolify
Results
Still in progress
The project continues. ABC Szalunki is moving to the system entirely from November 2026, and has set aside October for the whole team to work in the program and for online training. Open at the moment:
- Folders of document photos on Google Drive with a QR code on the printout: the code is ready and waiting for the client's account to be connected; photo preview in the system is in preparation
- Fetching company names from the GUS register (Statistics Poland): waiting for a key after the server move
- History of warehouse documents from Comotel: waiting for an export on the client's side
- A link to the accounting software and invoicing: the next stage, early 2027 at the earliest
- Further modules the client is considering as separate instances, so that a failure in one does not stop settlements
We will describe them once they are deployed. This case study will be updated.
What this project teaches
The biggest risk in a settlement system lies not in the code but in a rule someone remembers differently from how it is actually calculated. That is why this project began by reconstructing the formula from the spreadsheet and proving it with a calculation, not with screens. Once a client trusts the numbers, it is easier to trust everything else, and that is why a statement generator grew into a system that runs the company from quotation to warehouse reporting.
The second lesson is about data. Tests on examples prove that a rule is written correctly. Only a recalculation on the client's full data shows whether it is applied correctly. In a system that calculates money for other people's customers, you need both.
