Finance systems · Application engineering
Where configuration runs out, engineering begins.
Every platform reaches a point where a wizard and a dropdown menu cannot express what the business actually needs. That is where this service starts.
OneStream, Anaplan and the accounting systems beneath them all expose a business rules layer, and most implementations use it lightly. When a close process, a validation or an integration needs logic beyond what configuration allows, someone has to write it, test it and keep it working as the platform is upgraded around it.
This page explains what that work looks like, in SQL and VB.Net as much as in a platform's own scripting layer, and why it sits between integration and ownership rather than being treated as an afterthought.
From £5,000. A structured review of where configuration is running out, not a sales call.
Start here
Does the problem sound like yours?
This work rarely gets requested by name. It gets requested as a workaround that has stopped being sustainable.
A manual step propping up the close
Someone runs a spreadsheet macro or a manual query every period because the platform will not do the calculation the business actually needs.
A validation rule that cannot be built in configuration
The logic needed to catch a real error is more conditional than the platform's rule builder can express cleanly.
An issue nobody can reproduce
A defect appears intermittently in production and disappears in every attempt to recreate it, because nobody has isolated the actual trigger.
Extensions bolted on without a test plan
Previous customisations exist, but nobody knows what they will break if the platform is upgraded or the data structure changes.
What we do
Engineering discipline applied to finance platforms.
This is software engineering practice, brought to systems that are usually configured rather than built.
Business rules and application logic
Written in a platform's native scripting layer, or in SQL and VB.Net where the platform allows it, to express logic configuration genuinely cannot.
Issue replication and debugging
Isolating the actual trigger behind an intermittent defect, rather than guessing from the symptom, before proposing a fix.
QA and controlled extensions
Changes tested against a real regression plan before they reach production, with the test evidence kept, not just the change itself.
Documentation that survives the next person
Custom logic is documented so a future administrator, internal or otherwise, can understand and safely change it.
Still worrying about
Questions finance directors ask us.
Isn't this what the platform vendor's support desk is for?
Platform support handles defects in the product itself. Custom business logic, extensions and the integration code around a platform are the client's responsibility, and they are usually the least well understood part of the estate.
Can you fix logic someone else built?
Yes, and it is a large part of this work. Inheriting undocumented rules, tracing what they actually do, and either fixing or safely replacing them is common, particularly after a platform change of hands.
Do you write custom code inside OneStream and Anaplan, or outside them?
Both, depending on what is needed. Native business rules and formulas where the platform's own layer can express the logic cleanly, and SQL or VB.Net where the requirement sits in the integration or database layer around the platform.
What does this work cost?
It depends on the complexity of the logic and how much of the surrounding platform needs to be understood first. We scope and cost this work after a diagnostic, in writing, before any commitment.
Start with the diagnosis, not the platform.
A structured review of where configuration is running out and what it would take to fix properly. From £5,000, and the output is yours whether or not you go further.