What you get
- Live position by entity, job and account. What has been committed, what has been approved, what is owed and what is recoverable, as it stands right now rather than as it stood at the last close.
- Job and project profitability while it can still change. Cost against budget on a live job, so an overrun is a decision you make in week three rather than a discovery you make at handover.
- Cash in and cash out. Payables approved and due, receivables aged and chased, and what that means for the position in a fortnight.
- The exceptions, ranked. Not a wall of charts. The handful of things that are off, ordered by what they are worth, with a link to the underlying record.
- Reports that keep themselves. Saved and named, run on a schedule, delivered where the person actually reads them. Nobody rebuilds them each period.
- One number, one meaning. Because every module writes to the same registry, the figure on a report and the figure an agent acts on are the same figure. There is no reconciliation step because there was never a second copy.
- A morning brief. One page before the day starts: what changed overnight, what needs a decision, what is at risk. The thing most operators actually want instead of a portal they must remember to open.
Why this is different from a dashboard
We are not competing with the business intelligence tools, and if you already run one we will feed it rather than replace it. The distinction is where the numbers come from. A dashboard sits at the end of a pipeline: export, load, transform, reconcile, publish. Every stage is a place the number can drift, and the whole chain has to be maintained by somebody. Here the work itself, the invoice coded, the approval given, the timesheet submitted, the on-charge raised, happens in the portal. The report is that data read back. There is no pipeline to break because there is nothing to move.
That has a second consequence people underestimate. Because the report is the same data the system acts on, you can trust it enough to automate against it. A number assembled from three exports is a number you check. A number that is the record is a number you can act on.
The realities we build around
The people who most need the picture are the least likely to go and look for it. If it requires opening something, it needs to be delivered instead.
Month end is a reconstruction exercise in most businesses, and almost all of the effort goes into agreeing what the numbers are rather than deciding what to do about them.
Every business already has reports nobody reads. The problem is not volume, it is that the ones that matter arrive late and the ones that arrive on time do not matter.
A report that disagrees with another report destroys trust in both, and after that people go back to asking one person who "knows the real numbers".
Where most reporting projects go wrong
The usual failure is treating it as a visualisation problem. The patterns that fail: a warehouse built to consolidate systems that still disagree, which produces a faster route to a contested number; dashboards designed around what is easy to chart rather than what triggers a decision; scheduled reports that nobody opens because they arrive without a reason to; metrics defined differently in two places, so the argument moves from the numbers to the definitions; and self-service tooling handed to people who now need to learn a query language to answer a question they could have asked in a sentence. If a report does not change what somebody does that day, it is not reporting, it is decoration.
What it connects to
The modules already running in your portal are the primary source, because that is where the work happens. Beyond that: your accounting platform, your job or project system, your payroll, and any business intelligence tool you already operate, which we feed rather than replace. We do not publish a supported-vendor list: line of business applications, online software, on premise or in the cloud. If it holds the data, we integrate with it, and if it is not named here that is not a limitation.
Where the human stays in the loop
Reporting does not make decisions and we are careful about the line where it starts implying them. Every figure links to the records behind it, so a number can be interrogated rather than believed, and anything the system could not source is shown as missing instead of quietly excluded. Where a report drives an automated action, that rule is something you set explicitly and can see, not something inferred on your behalf.
How an engagement runs
- Map the rules. A discovery sprint captures how this actually works in your business today, including the parts nobody has written down. You get a recommended architecture and a fixed-price build quote.
- Build against your systems. Against your real data and your real structure, with the human approval steps designed in from the start rather than bolted on.
- Validate on real work. We run it against what your team actually receives and tune it until it holds up on the messy cases, not the clean ones.
- Hand over and operate. Working, in your environment, with a runbook and full ownership. Extend as a build or a retainer.
What it costs
Most teams start with a discovery sprint from $7,500 to map the rules and produce a fixed-price build quote, or an Automate Your Role engagement from $12,000 for a tightly scoped first version. A full build starts at $40,000 and scales with the complexity of your rules and the number of systems involved.
After the build you choose how to hold it: a monthly subscription covering hosting, monitoring, model costs and ongoing tuning, or a perpetual licence purchased outright, where you own the deployment and support is available separately on a retainer.
Common questions
Do we need to replace our BI tool?
No, and usually you should not. If you already run one we feed it clean, current data rather than competing with it. What we replace is the assembly work in front of it, which is where the cost and the drift actually are.
How is this different from a dashboard we could build ourselves?
You could build the charts. The hard part is that the numbers underneath come from systems that disagree, and keeping them agreeing is a permanent job. Here the work happens in one place, so the report is the record rather than a copy of it.
Can we still do month end?
Yes, and it gets shorter. Most of a close is agreeing what the numbers are. When the coding, approval and on-charge decisions were all made in the system as the work happened, that part is already done.
What if our data is a mess right now?
That is the normal starting point and it is worth saying plainly: reporting will not fix it. Reporting will show you exactly how messy it is, which is usually the argument for fixing the underlying process. We would rather start with the module that cleans the data at the source than sell you a chart of the problem.