A core accounting system that is properly designed does four specific things: enforces authority instead of describing it, makes compliance the path of least resistance, automates routine transactions, and produces finished outputs rather than raw inputs. But trying to solve operating design during an active build is like trying to fix an aeroplane while it's flying. If you don't pause to untangle workflows before engaging vendors, you end up spending a fortune just to rebuild the exact bad habits of your old system inside a shiny new platform.
The time spent before you engage system vendors and attend product demos is the highest-leverage investment an organisation can make in a transformation project. Map the processes first. Interrogate the legacy habits. Agree the delegation of authority. Then, and only then, design the system architecture and work through the functional requirements, then select and configure the tool to match the design.
A properly designed system enforces four structural disciplines, whether people ask it to or not.
It enforces authority rather than describing it. Most organisations have a board-approved delegation of authority policy setting out exactly who can approve what, and at what threshold. The system should mirror that policy precisely, not the other way around. Too often, a platform's default limitations quietly redefine what delegation looks like in practice, and the tail ends up wagging the dog. Build the rules the board actually approved directly into the platform, and approvals stop being a persistent chase and become automatic routing.
It makes the standard path the easy path. Purchase orders, matching tolerances, verified supplier bank details, and mobile expense acquittal at the point of spend. When compliance is the easiest route available, the finance team stops wasting time policing colleagues.
It processes the ordinary case without human touch. Lifting touchless invoice matching from 10% to above 80% doesn't just cut transaction costs, it transforms roles. Accounts payable staff shift from keystrokes and filing to exception handling and supplier relationship management.
It produces the output, not the inputs. A month-end pack that takes days of manual assembly represents dozens of hours of copy-paste drudgery, repeated twelve times a year, indefinitely. The system should generate the pack so the team can spend those days reading it instead of compiling it.
Get those four disciplines right and you build a motivated, forward-looking team. Not because anyone asked them to work harder, but because there is simply less mechanical work left to do.
The sequencing trap: fixing the plane mid-flight
A costly error we see often is organisations expecting a vendor or implementation partner to supply the operating design, when they rarely have the coalface experience of running a finance team, or living with the consequences of their own decisions.
It usually happens because the team is drowning, everyone's under the pump, and nobody has the bandwidth to redesign workflows before the project starts. So they try to design process on the fly, mid-implementation, which is like fixing an aeroplane while it's flying: delivery pressure and budget burn take over, and nuance gets abandoned to keep things on track.
When you don't invest time before engaging vendors, your team naturally retreats to what they know. When asked by an implementer how a module should work, the default response is simply: "Just set it up the way we did it in the old system."
The result wrecks your ROI: you spend five or six figures on modern software, only to pave over old cow paths and hardcode legacy workarounds into a brand new interface.
The sequence always matters more than the vendor.
Accounting System Design & Implementation. Design the target operating model and architecture first, then configure the platform to fit, not the other way around.
See how it works