The three-day budget bottleneck that became a few-hour task

"Turned a three-day process into a few hours" is the kind of line that belongs on a case study card, but it raises an obvious question: which part of the budget process actually took three days, and why did fixing it take building an application instead of, say, a better spreadsheet template?

Where the three days went

Ministry budget entries were prepared over several months. Once the entries were complete, the data still had to be loaded into the government accounting system, reports had to be generated, and the completed budget had to be printed. That completion stage could take three days, much of it spent correcting errors that blocked the import and exchanging revised files.

The overall process also became faster because ministries no longer had to email files back and forth, but the largest improvement was the completed- budget import, reporting, and printing stage.

What the application changed

The fix wasn't just a smarter spreadsheet. It was a browser-based budget application that allowed ministries to log in and enter account records, with validation and approval built directly into the workflow for budget approvers. It replaced emailed files with a proper flow from data entry through validation and approval, backed by a reliable database as the single source of truth. At the final stage, importing completed entries, generating reports, and printing became one reliable workflow that took a few hours, depending on import volume.

Why this generalises

The specific technology here — Vue.js, SQL Server, IIS — matters less than the pattern: find where a process is actually losing time (almost never where people assume), and remove the hand-off, not just the tool. A lot of "we need custom software" conversations start with a request for a nicer version of the current tool. The better question is usually where the current tool's users are losing time to something the tool itself can't see.