3 September 2026LANTEK Computers
There is a particular support call that comes in around the same time every month. Sage has gone slow, or somebody cannot post because a record is locked by a user who went home, or the whole thing fell over mid invoice run and now nobody wants to touch it until somebody senior is watching.
The instinct is to blame the software. In our experience it very rarely is. A multi user accounting package is one of the most demanding things a small business network is asked to do, and most small business networks were never built with it in mind. The package is simply the first thing that notices.
Why accounting software is harder on a network than anything else
Most of what a business does over a network is forgiving. A document opens, you edit it, you save it. If the connection stutters for a moment, nothing much happens.
A shared accounting data file does not work that way. Several people are reading and writing to the same file at the same time, and the software has to keep every record consistent while they do it. To make that safe, it locks records, and it expects the storage underneath to confirm each write promptly and reliably.
That means it is sensitive to two things that other software shrugs off: latency, which is how long each small operation takes to come back, and any interruption at all, however brief. A connection that is technically fast but inconsistent will give you a slow, unstable accounting package while everything else on the same network seems fine. This is the single most common reason people conclude the software is at fault.
The causes we actually find, roughly in order
The data file lives on somebody’s desktop machine
This is the most common arrangement in a small business and the most consequential. It usually happened for a good reason: the bookkeeper set it up, everybody else was pointed at their machine, and it worked.
The problems it creates are structural. That machine has to be on for anybody to work, so it never gets shut down or updated properly. When it sleeps or reboots, everybody else is disconnected mid transaction. It is a desktop operating system handling file sharing for multiple users, which it is not designed for. And it is almost never included in the backup, because the backup was scoped to the server.
The fix is to move the file to proper shared storage. Not because a server is fashionable, but because the file needs to live somewhere that stays on, gets backed up, and is not also somebody’s daily computer.
Wireless
Any machine running accounting software over Wi-Fi will eventually corrupt something. Wi-Fi drops packets and reconnects as a matter of normal operation, and while that is invisible for browsing, it is exactly the interruption a shared data file cannot tolerate mid write.
This is not a tuning problem. Put the machines that post transactions on a cable. If that is genuinely impossible because of where somebody sits, the answer is to change how they access it rather than to hope, which usually means running the session on the server instead of the file across the wireless.
Antivirus scanning the data file on every operation
Security software watching every file change is doing its job. Applied to an accounting data file being written to hundreds of times a minute, it adds a delay to each one, and the effect compounds badly at month end when volume is highest.
The correct fix is a narrow exclusion for the specific data file and its working files, on both the server and the workstations, and nowhere else. Two cautions worth stating: excluding an entire drive or an entire folder tree because it is quicker is how you create a genuine security gap, and the exclusion must be recorded so that whoever inherits the estate knows it exists and why.
The switch, the cable and the socket nobody has looked at
An unmanaged switch that has been in a cupboard for years, a cable that was crimped by hand, or a wall socket that was never certified will all produce errors that get automatically retried. Nothing appears broken. Everything is just slow, intermittently, and worse when the network is busy.
This is unglamorous and it is frequently the answer. It is also cheap to establish: the switch will tell you it is discarding traffic if anybody looks.
Nobody has closed the month, ever
Not a network problem, but it belongs on the list. A data file carrying years of open transactions gets slower because there is more to work through. Housekeeping inside the package, done with your accountant, sometimes achieves more than any infrastructure change.
Records locked by somebody who has gone home
This is the one that causes the most friction between finance and IT, because each thinks it belongs to the other.
What usually happened: somebody had a record open, their machine slept or lost the network, and the lock was never released cleanly. The record now belongs to a session that no longer exists.
Clearing it is straightforward for whoever supports the system. Stopping it recurring is the actual work, and it is mostly about the machines rather than the software: preventing them sleeping while a session is open, having people close the package before they leave rather than locking the screen, and dealing with the wireless problem above.
What you should not do is develop a habit of resetting things at the file level to clear locks. That is how a data file gets damaged in a way that a restore is the only answer to.
Which brings us to the backup
Two things about backing up accounting data that catch businesses out.
First, a backup taken while the file is open and being written to may not be usable. A file level copy of a live data file can capture it mid transaction. The backup needs to be taken in a way that accounts for the file being in use, or taken when it is not.
Second, and more important: a backup you have never restored from is not yet a backup. Accounting data is the thing a business least wants to rebuild by hand, and it is the thing most often found to be unrecoverable at exactly the wrong moment. Restore it, deliberately, once, and write down that you did. That argument is made at greater length in how to test a backup and backup is not disaster recovery.
What to check first, if you are looking at this yourself
In this order, because it goes from most likely to least.
Where does the data file actually live, and is that machine somebody’s desktop. Is every machine that posts transactions on a cable rather than wireless. Are there antivirus exclusions in place for the data file, and are they narrow and documented. Is the switch reporting errors. Has the month ever been closed.
Four of those five you can answer without any technical help, and they account for most of what we find.
Getting somebody else to look
What we do around Sage is set out on Sage Accounting, and the network side of it sits with IT Infrastructure. If month end has become something the business braces for, tell us what happens and when. The pattern of when it goes wrong usually points straight at which of the five above it is.