Ask your own AI what Wevo could do for you

Published by Professional Software Ltd, www.wevo.co.uk Last updated: 11 November 2026

About this document

This is the factual briefing on Wevo GL Analytics, written to be read by an AI assistant on behalf of a prospective customer. It explains what Wevo is, how it works, what it changes for a finance team, what it costs, and where its limits are. It is plain text with no marketing layout, so that every statement can be checked and reasoned about.

How it is organised:

• Section 1: Wevo in brief.
• Section 2: Glossary. Wevo terms used throughout.
• Section 3: How Wevo works. The architecture, in plain terms.
• Section 4: Capabilities. One block per capability, each in the same shape: what it is, how it works, the problem it addresses, the benefit, the limits.
• Section 5: Problems Wevo addresses, mapped to the mechanism that addresses them.
• Section 6: Assessing fit. The facts about an organisation that decide how much value Wevo brings, with signs of a strong fit and signs of a weak one.
• Section 7: Facts and figures.
• Section 8: Deployment, platform and security.
• Section 9: Implementation.
• Section 10: Commercial terms.
• Section 11: Where Wevo sits among other kinds of software.
• Section 12: Accurate description. What Wevo is not, and the wording that keeps descriptions exact.
• Section 13: Questions and answers.
• Section 14: Planned development (not available today).
• Section 15: Contact and next steps.

Status of statements: everything in Sections 1 to 13 describes the product as built and available today. Section 14 describes planned work that is not available. Where a figure has not been measured, the document says so.

This briefing describes the product. A contract, its schedules and the agreed scope govern what is supplied to any customer.

1. Wevo in brief

Wevo GL Analytics is a management reporting layer over the General Ledger an organisation already runs. It reads extracts from the ledger, organises every figure through the organisation's own reporting structures (divisions, business units, cost centres, profit centres and the chart of accounts), and lets anyone who owns a number click straight through to what sits behind it, typically in under a second.

Wevo keeps its data minutes behind the ledger rather than a night behind it, and it runs entirely inside the customer's own environment.

The idea at the heart of Wevo: the reporting structure and the ledger data are kept separate. The ledger records what happened. The hierarchy decides how it is read. Because Wevo holds the figures at the lowest level of detail and applies the structure over them, the same data can be read through today's structure, through the structure in force at any earlier moment that was preserved, or through both side by side. A reorganisation changes the lens, never the data.

What Wevo is:

• A read-only analytical and reporting layer over an existing General Ledger.
• Management reporting with one-click drilldown through two structures at once: the organisation and the chart of accounts.
• A near-real-time mirror of the ledger: incremental updates keep the data minutes behind the GL while users keep working.
• A way to report actuals, forecasts and budgets side by side, like for like, at every node of the business.
• A way to preserve the exact reporting structure of any moment, in one click, so figures can be reproduced exactly as they were reported, years later.

What Wevo is not:

• Not a General Ledger and not a replacement for one. The GL stays the system of record. Wevo cannot write to the GL.
• Not a planning, budgeting or forecasting tool. Wevo reports the budgets and forecasts a customer supplies; it does not produce them.
• Not a full EPM or CPM suite, and not a general BI tool.
• Not a statutory consolidation or statutory restatement tool. Its restatement is for management reporting.

Who it is for: finance teams (CFOs, Financial Controllers, FP&A, management accountants, budget holders) in organisations whose ledger does not give them a fast, structured, trustworthy view of the business, especially groups with many entities, frequent reorganisations, acquisitions or disposals, regulated environments, or a costly legacy reporting workload.

Heritage: the first version of Wevo was built in the early 2000s on IBM mainframes and was adopted by major UK clearing banks for cost centre and profit centre reporting. The current product re-engineers that proven Tier-1 banking logic as a modern platform that runs on one ordinary server. The founder has more than 25 years of experience as a senior technical business analyst across financial services and the public sector.

2. Glossary

General Ledger (GL): the customer's accounting system of record. Wevo reads extracts from it and never writes to it.

Segment value: a code in the GL's account string, such as a cost centre, an entity or a natural account. Wevo holds figures at segment-value level.

Hierarchy: a tree that groups segment values into a reporting structure. Wevo uses two at once: - the organisational hierarchy (also called H1 or Org): entities, divisions, business units, cost centres; - the account hierarchy (also called H2 or Acc): the chart of accounts grouped into reporting lines, for example revenue, cost of sales, overheads.

Node: one point in a hierarchy, from the top of the group down to a single segment value. A leaf node is a segment value at the bottom of a hierarchy.

Node pair: one organisational node together with one account node, for example "Northern Region" x "Travel Costs". Every figure in Wevo is the value of a node pair. The leaf intersection (segment value x account) is the lowest level of detail.

Cube: the definition that pairs an organisational hierarchy with an account hierarchy for a record type (actuals, budgets or forecasts), years and a version. Wevo calculates and stores every roll-up of a cube in advance, which is why drilldown is immediate. The same ledger data can be summarised through more than one cube at the same time.

Drilldown: clicking a figure to see the figures beneath it, down to the leaf intersection.

Summarisation: Wevo's calculation of every roll-up in a cube from the leaf-level figures. It is done in advance, not when a user asks.

Full balance build: a complete rebuild of the data from a balances extract, scheduled out of hours (for example late on a Saturday). It also puts promoted hierarchy changes live.

Incremental load: an update from a movements extract, applied during the working day while users keep working.

Movements: the accumulated postings since the last movements clear-down, which the customer schedules (for example weekly, at 6 am on Monday). Daily movements are a separate view of what has hit the ledger today.

Period model: a Wevo year holds 16 periods, either 12 trading periods plus 4 close periods or 13 trading periods plus 3 close periods, plus an opening balance: 17 columns per year.

As-is reporting: reading every year through today's structure, for like-for-like comparatives with no restatement work.

As-was reporting: reading a year through the structure that was in force at the time. Delivered by Preserve Structure.

Preserve Structure: the one-click function that copies the production organisational and account hierarchies, as they stand, into a preserved cube.

Preserved structure, dormant cube: the result of Preserve Structure. It is a definition, not a dataset. It holds no data and uses no processing until a year is allocated to it and it is activated.

Promote: the step that locks a changed hierarchy and schedules it to go live at the start of the next full build.

Development and production: the two environments included in every licence. Changes are prepared in development and reach production only through promotion.

Watched node pair, watchlist, snapshot: a node pair placed on a cube's watchlist. Each time an incremental update recalculates it, Wevo records a time-stamped snapshot of its values.

Variance comment: a short written comment, with the author and the date and time, attached to a node pair in the drilldown.

Security profile: what a user may see in a hierarchy, defined as a node and everything beneath it, or a level and everything beneath it.

3. How Wevo works

3.1 The data flow

1. The customer's GL produces flat file extracts (CSV): segment values, hierarchies, balances and movements. The customer builds and schedules the extract; Wevo provides a file specification and a guide to building it. Extracts can be triggered by time, by the amount posted, by the number of postings, or by whichever comes first.
2. The files are placed in a landing folder with a ready signal. Wevo's Summarisation Engine validates each file, loads it and summarises it. A file that fails validation is quarantined, not half-loaded.
3. Summarisation calculates every roll-up of every active cube, through both hierarchies, and stores it. Incremental updates recalculate only the nodes that changed and their ancestors, at around 4 million summarised rows per minute.
4. Users open the drilldown in a web browser and navigate the pre-calculated figures. Reports are produced from the same figures and can be requested by email.

There is no live connection to the GL. Wevo cannot query, change or slow the ledger. Any GL that can produce structured extracts can feed Wevo: SAP, Oracle, Microsoft Dynamics, Sage, mainframe ledgers and others.

3.2 Why structure and data are kept separate

Most reporting tools store figures already shaped by the reporting structure of the day. When the structure changes, the stored figures no longer match it, so history is restated by hand, remapped, or lost.

Wevo stores the figures at leaf level (segment value x account) and holds the hierarchies as separate objects. Every roll-up is calculated by applying a hierarchy to the leaf-level data. Three consequences follow:

1. Any structure can be applied to any period. Prior years can be read through today's structure (as-is) or, if it was preserved, through the structure in force at the time (as-was), from one dataset, with no restatement exercise.
2. A structure can be parked and recombined later. A preserved structure costs under 1 MB for an enterprise group and holds no data until it is needed.
3. A reorganisation costs nothing in reporting terms. The lens changes; the postings do not. Nothing is restated, no comparative is lost, and no report definition is rewritten.

This is a decision taken in the data model. A product that bakes the structure into its stored figures cannot add it later as a module.

3.3 Staying current while people work

Wevo keeps two copies of its summarised tables (an A side and a B side). An incremental update writes to the copy users are not reading, then switches them over, one cube at a time, starting with the current year. Users keep working throughout incremental loads, and the most-used data is refreshed first.

The weekly full balance build is different: it clears down and rebuilds the data, so it is scheduled out of hours and Wevo is not used while it runs. Email report requests wait and are retried automatically until it finishes.

3.4 History stays in step with the ledger

There is no frozen year in Wevo. Every year allocated to Wevo is kept synchronised with the GL. A prior-year adjustment or an audit correction posted today appears in Wevo minutes later, at every level of both hierarchies, like any other posting. There is no static archive drifting away from the ledger to reconcile.

From go-live, Wevo can summarise prior years already held on the GL through the current structure, so like-for-like comparatives are available on day one rather than after a year of running.

4. Capabilities

4.1 Drilldown through two structures at once

What it is: one-click navigation from any consolidated figure to the lowest level of detail, through the organisation and the chart of accounts together.

How it works: the screen shows the organisational hierarchy and the account hierarchy side by side, each with its ancestry (grandparent, parent, current node) and children. A user moves up, down or sideways in either hierarchy, or picks any level and any node from a list. A selector chooses which hierarchy's children are broken down in the grid. Every roll-up is pre-calculated, so each step typically returns in under a second. The selection (years, periods, currency, notation, scaling) is kept at every step.

The problem it addresses: drilldown that means exporting to a spreadsheet, raising a ticket, or waiting hours for a query; and reports that show a total but not what makes it up.

The benefit: anyone who owns a number can see where it comes from, at the level they manage, without help from IT or a report writer.

Limits: the lowest level is the leaf intersection (segment value x account). Wevo holds accumulated values, not individual journal lines; seeing the individual GL transactions behind a leaf value needs a query on the source GL.

4.2 Data views and display options

What it is: the choices that shape what the grid shows.

How it works: - Data types: GL balances; movements (accumulated since the last clear-down, which the customer schedules, for example weekly); daily movements (what has hit the ledger today). - Up to 9 years side by side. - Calculation: Cumulative (from the opening balance to a chosen period), Net (the movement between two periods) or By period (each period on its own). - Currency: base currency (consolidated) or source currency (original). - Scaling: units, thousands or millions. - Debit and credit notation: Dr, CrDr, accountant's brackets, or a trailing minus. - Column titles name the type, the fiscal year and the period range, for example "Forecast FY26 YTD P12". Six columns are shown at a time, with buttons to move one column, one group (a year or period with its forecast and budget) or one page. A plain-English line above the grid states the selection. - CSV export of the breakdown for spreadsheet analysis, including any variance comments.

The benefit: one screen answers balance, movement and trend questions in the notation and scale the finance team already uses.

4.3 Actuals, forecasts and budgets side by side

What it is: actuals, forecasts and budgets summarised through the same hierarchies and shown side by side in the drilldown and the CSV export.

How it works: budgets and forecasts arrive through the same feed as actuals and are summarised through the same structures. A Forecasts button and a Budgets button add the comparison columns; for each year or period the columns run actual, forecast, budget. Hovering over a forecast or budget column shows the variance of the actual against it, calculated as a finance team would: variance = actual minus budget (or forecast), and the percentage = variance divided by the absolute value of the budget (or forecast). Multiple budget versions (for example original, revised and final) can be held side by side, and dedicated budget hierarchies can be set up for a cube. The profit and loss report can include budget columns.

The problem it addresses: actuals in one place, the budget in a spreadsheet and the forecast in a planning tool, put together by hand at month end, and never at the level the business is managed.

The benefit: one place, at every node, like for like. Because all three go through one structure, a restructure moves all three together and nothing has to be remapped.

Limits: Wevo reports budgets and forecasts; it does not produce them. Budgets and forecasts are compared for balances (not for movements). The variance is not labelled favourable or adverse, because that depends on whether a line is income or expense.

4.4 Near-real-time updates

What it is: the data stays minutes behind the ledger, not a day.

How it works: movements extracts are processed incrementally as they arrive, cube by cube, current year first, with the A/B switch keeping users working (Section 3.3). How current the data is depends on how often the customer's extract runs; in practice extracts every 15 to 30 minutes are typical.

The problem it addresses: decisions made on yesterday's figures; close week spent waiting for an overnight batch to see whether a correcting journal landed.

The benefit: managers see period-to-date, week-to-date and day-to-date movement without querying the GL. A late journal in close week is visible within minutes.

Limits: near-real-time, not instantaneous. The weekly full balance build runs out of hours and Wevo is not used while it runs.

4.5 As-is comparatives through today's structure

What it is: every year read through the current structure, automatically.

How it works: because figures are held at leaf level, the current hierarchies are applied to every allocated year at each full build.

The problem it addresses: "not like for like" footnotes after every reorganisation, and manual restatement of prior years in spreadsheets.

The benefit: like-for-like comparatives at every node after any restructure, with no restatement work, from go-live.

4.6 Preserve Structure: as-was reporting and point-in-time evidence

What it is: a one-click function that preserves the exact organisational and account structure in force in production at that moment, so the figures can be reproduced exactly as they were reported, at any time in the future.

How it works: on a cube, the user enters a name and a mandatory reason and presses Preserve Structure. In one transaction, Wevo copies both hierarchies from production (with all levels, nodes and links), locks them, creates a preserved cube on them and records the reason. The preserved cube is dormant: it holds no data and takes no part in any build. It occupies under 1 MB for an enterprise group. When the old view is wanted, the customer allocates the year (or years) and activates the cube; the next full build calculates the figures from the retained leaf-level data through the preserved structure. When it is no longer needed, the cube is made inactive and its data is deleted; the definition remains.

A preserved structure cannot be amended, only deleted. That is what makes it usable as evidence of the structure genuinely in force at the time.

The old and the new structure can be reported side by side for the same year, so the effect of a restructure is calculated, not estimated.

The problem it addresses: after a reorganisation, acquisition or disposal, the structure that gave past figures their meaning has been overwritten. Reproducing "what we reported then" normally means restoring old backups, standing a retired system back up, or rebuilding the mapping by hand in spreadsheets: slow, unauditable, and rarely exact. The question usually arrives from an auditor, a regulator, an acquirer, a tribunal or a board, never at a convenient moment.

The benefit: insurance that costs almost nothing and cannot be bought after the event. Because a preserved structure costs under 1 MB and no processing, there is no need to judge which structure will matter later: preserve before every change and monthly as routine, and decide later. The reproduction is exact, because it is the same leaf data aggregated through the same structure.

When to use it: before any reorganisation; before an acquisition, merger or disposal and again at completion; at each year end and monthly or quarterly as routine; before a chart-of-accounts change, an entity renumbering or a cost centre rationalisation.

Limits: preservation is user-initiated, not automatic; somebody presses the button, so it is a matter of the customer's policy. It must happen before the change: once a hierarchy has been restructured and promoted, the previous arrangement cannot be copied from production. The figures for an activated preserved cube are calculated at the next full build, not instantly; activation time has not yet been measured. Preserve Structure is included from the Group tier upward (Section 10).

4.7 Governed self-service hierarchies

What it is: finance owns and maintains the reporting structures, with control.

How it works: any hierarchy, including one in production, can be edited in the development environment (levels, nodes, moves, new cost centres). Batch input and CSV export and re-import support large changes and offline work. Each hierarchy is validated. When it is ready, a button sets it to promote status and locks it; it goes live at the start of the next full build. Complex reorganisations can be prepared over days or weeks and deployed in one controlled build. Every change is logged with the user's name and the time. A hierarchy can have up to 20 levels, with no limit on nodes or segment values.

The problem it addresses: every hierarchy change being an IT ticket and a wait; or, the opposite risk, uncontrolled changes to live reporting.

The benefit: self-service with segregation of duties. The people who understand the business maintain the structure; nothing reaches production unreviewed.

4.8 Multi-entity, multi-currency consolidation

What it is: group views across entities, charts of accounts and currencies.

How it works: the organisational hierarchy can span many entities; base currency and source currency views are both available; several cubes can summarise the same data through different structures.

The problem it addresses: group management accounts assembled in spreadsheets from several ledgers or charts of accounts.

The benefit: a near-real-time group view at every level, with drilldown to the entity and the cost centre.

Limits: management consolidation, not statutory consolidation.

4.9 Management accounts by email

What it is: reports requested and delivered by email, with no licence seat and no login.

How it works: each authorised user receives a report request form by email (for example every Monday). The form lists only the reports their security profile allows. The user adjusts the parameters (nodes and levels within their profile), sends the pre-addressed email, and the finished report returns to their inbox, usually within minutes, produced from the current figures. Each request is validated against the sender's registered address, a security token issued to that user and their profile. Reports arrive as a ZIP attachment, optionally AES-encrypted with a per-user password. Formats: TXT, PDF, HTML and CSV. Supplied reports: trial balance and profit and loss. Other reports (for example balance sheet or cost centre expenditure) can be built for a customer.

The problem it addresses: report consumers who each need a paid seat, or who wait for someone in finance to run and send a report.

The benefit: unlimited recipients at no extra cost, self-service, near-live figures, every request audit-logged.

Limits: during the weekly full build, requests wait and are retried automatically.

4.10 Variance comments

What it is: a short written explanation attached to a node pair, beside the figures.

How it works: an authorised user adds a comment of up to 100 characters to the node pair in focus. It records the user and the date and time and is shown to everyone who can see that node pair. Comments cannot be edited or deleted by users (a correction is a new comment), so what was said stays on the record. The page shows the 50 most recent; the CSV export carries all of them.

The problem it addresses: the explanation for a variance lives in an email or a spreadsheet, not beside the number.

The benefit: the explanation sits with the figure, with who said it and when, in the screen people already use. No separate commentary system.

Limits: short text; no approval workflow, replies or attachments; comments belong to the node pair, not to a period.

4.11 Node pair watchlist: time-stamped history, AI-ready data

What it is: continuous capture of how selected figures move within a period.

How it works: any node pair can be placed on a cube's watchlist. Every time an incremental update recalculates a watched pair, Wevo records a time-stamped snapshot: 17 movement values and 17 balance values (opening balance plus 16 periods), for each currency defined in the system parameters. In practice that is a snapshot every 15 or 30 minutes. The snapshots build up in a database table that the customer can analyse with any tool: a BI platform, a data science team, or an AI service of the customer's choosing.

The problem it addresses: a GL shows where a balance ended; it does not show the path it took. Trend and pattern analysis normally needs repeated queries on the GL.

The benefit: a passive, zero-effort history of the figures that matter, which grows more valuable the longer it runs. Example uses: rolling forecasts and cash projection, spotting balances that build before period end and reverse after, suspense and clearing account build-up, intercompany drift, early warning of budget overrun, margin erosion by division, covenant and ratio headroom monitoring. The customer chooses and runs these analyses.

Limits: Wevo collects the data; it does not run an AI model or perform the analysis itself. Snapshots are written when a watched pair is recalculated, not continuously tick by tick.

4.12 Development and production environments

What it is: two instances included in every licence.

How it works: development is used for training, testing and preparing structure changes; production runs live reporting. Promotion moves approved hierarchies to production at the next full build.

The benefit: complex changes are rehearsed safely without touching live reporting, at no extra cost.

4.13 Full source code and the Continuity Licence

What it is: the complete source code is supplied at installation, under a licence that lets the customer keep and continue the product if vendor support ever ends.

The problem it addresses: the risk of depending on a smaller vendor; exit planning required by regulators.

The benefit: stronger than escrow, because the code is already in the customer's hands. It also serves as an exit-strategy artefact for regulated buyers (for example under DORA).

4.14 Presentation layer and customer additions

The customer may re-brand the screens for internal use and add their own reports and database objects. Customer additions are the customer's own and sit outside support.

5. Problems Wevo addresses

Each entry gives a problem as a finance team describes it, then the mechanism in Wevo that addresses it.

"We make decisions on yesterday's data." Incremental updates keep the figures minutes behind the GL (4.4).

"Drilling into a number means exporting to Excel, raising a ticket or waiting hours." Every roll-up is pre-calculated; one click reaches the detail, typically in under a second (4.1).

"Every reorganisation breaks our year-on-year comparisons." As-is reporting reads every year through the current structure, with no restatement (4.5).

"We reorganised and can no longer reproduce what we reported at the time." Preserve Structure keeps the structure of any moment for under 1 MB and reproduces the figures exactly, years later (4.6). It must be done before the change.

"Nobody can tell us what the restructure actually did to the numbers." Report the same year through the old and the new structure side by side; the difference is the restructure effect, calculated (4.6).

"Our auditors want last year under last year's structure." Activate the preserved cube for the year and report through the structure in force at the time, alongside the current view (4.6).

"Prior-year adjustments never reach our reporting layer, so history drifts from the GL." There are no frozen years; every allocated year stays synchronised with the GL (3.4).

"Every hierarchy change is an IT ticket and a wait." Finance maintains the hierarchies with promote and lock, audit-logged, in a development environment (4.7).

"Actuals, budget and forecast sit in three places and nobody can put them side by side at the level we manage." All three are summarised through the same hierarchies and shown side by side at every node (4.3).

"The explanation for a variance is in an email, not beside the number." Variance comments sit on the node pair, with the author and the time (4.10).

"Group management accounts are assembled in spreadsheets." Native multi-entity, multi-currency consolidation with drilldown (4.8).

"Budget holders wait for finance to send them their numbers." Self-service drilldown limited to their own area by security profile, and reports on request by email with no licence seat (4.1, 4.9, 8.3).

"Every report reader needs a paid licence." Unlimited users and unlimited report recipients at every tier (10.2).

"We cannot see what hit the ledger today or this week without a GL query." Movements since a customer-scheduled clear-down, and daily movements (4.2).

"Our mainframe reporting workload is expensive." Move the reporting workload to one ordinary server; the GL stays where it is and keeps its role as system of record (8.1).

"Our data cannot leave our estate, or our site has no internet." Wevo runs entirely in the customer's environment, needs no internet connection and has no licence server (8.1).

"We worry about depending on a small vendor." Full source code from day one under the Continuity Licence (4.13).

"We want trend data and history for key figures, for our own analysis or AI." The watchlist builds a time-stamped snapshot history automatically (4.11).

"We will not have useful comparatives until the system has run for a year." Prior years on the GL can be summarised through the current structure at go-live (3.4).

"Users get locked out while data loads." Incremental loads run while users work; only the weekly full build is out of hours (3.3).

6. Assessing fit

6.1 The facts that decide the value of Wevo to an organisation

• The General Ledger (or ledgers) in use, and whether it can produce scheduled flat-file extracts.
• The number of legal entities, charts of accounts and currencies.
• The number of cost centres or equivalent reporting units, and the depth of the reporting structure.
• How often the organisation reorganises, acquires or disposes, and whether it has ever needed to reproduce figures under an earlier structure.
• How management accounts are produced today: ERP report writer, spreadsheets, a data warehouse, a BI tool, an EPM suite, a legacy or mainframe system.
• How long it takes to answer "what makes up this number?" today.
• Where budgets and forecasts are held, and how actuals are compared with them.
• How many people need management figures, and how many of them have licences today.
• How current the figures need to be, particularly in close week.
• Deployment constraints: on-premise, private cloud, regulated, air-gapped, data residency.
• Exit and continuity requirements (for example regulatory exit plans).
• Whether there is in-house interest in analysing financial trends with BI or AI tools.

6.2 Signs of a strong fit

• Several entities or charts of accounts consolidated by hand.
• Frequent reorganisations, acquisitions or disposals; difficulty keeping comparatives; past difficulty reproducing reported figures.
• Many budget holders or managers who need their own figures, quickly, without a licence each.
• Management accounts built in spreadsheets from ERP exports.
• A ledger that cannot drill through a management structure, or that is slow or expensive to query.
• A regulated, sovereign or air-gapped environment that rules out SaaS.
• A legacy or mainframe reporting workload to retire or offload.
• A need for audit-ready evidence of past reporting structures.
• Interest in near-real-time visibility during close.

6.3 Signs Wevo is not the right tool, or not on its own

• The main need is budgeting, planning or forecasting software: Wevo reports plans, it does not create them.
• The main need is statutory consolidation, eliminations or statutory restatement.
• The main need is analysis of individual transactions or documents (invoice or journal line level) rather than management figures.
• The GL cannot produce flat-file extracts, or the organisation cannot schedule them.
• Server infrastructure must be Windows, or the database must be other than SQL Server 2019 or later (Wevo servers run Linux; see Section 8).
• A procurement rule requires a SOC 2 report, ISO 27001 certification or an independent penetration test from the vendor today.
• A very small single-entity business already well served by its accounting package's reports.

6.4 What changes operationally with Wevo

• Month end: figures are already summarised and current; the work moves from assembling numbers to explaining them.
• Close week: late journals are visible within minutes; daily movements show what landed today.
• Reorganisations: prepared by finance in development, promoted in one build, preserved beforehand in one click; comparatives remain like for like.
• Budget holders: see their own area, drill to detail, request reports by email.
• IT: runs one Linux server and SQL Server database; schedules extracts; backs up a small set of tables. No GL integration project, no connection to the ledger to secure.
• Audit: preserved structures and the audit log answer "what was in force and who changed what".

7. Facts and figures

Performance and scale: - Drilldown response: typically under 1 second (all roll-ups pre-calculated). - Currency of data: minutes behind the GL, depending on the extract schedule; typical extracts every 15 to 30 minutes. - Summarisation throughput: around 4 million summarised rows calculated and updated per minute. - Demonstrated scale: 25,000 organisational hierarchy nodes and 5,000 chart of accounts nodes. The architecture imposes no limit on nodes or segment values. - Hierarchy depth: up to 20 levels. - Years: up to 9 years side by side. - Periods: 16 per year (12 trading + 4 close, or 13 trading + 3 close), plus an opening balance = 17 columns per year. No weekly periods. - Maximum virtual columns: 459 (9 years x 17 periods x actuals, forecasts and budgets); a theoretical maximum, not a typical display. Six are shown at a time. - Preserved structure: under 1 MB for an enterprise group; no data and no processing while dormant. - Watchlist snapshot: 34 values (17 movements and 17 balances) per currency. - Variance comments: up to 100 characters; the page shows the 50 most recent. - Users and report recipients: unlimited. - Implementation: typically 6 to 10 weeks to live reporting; hierarchy migration typically 1 to 2 weeks; user training typically 2 to 3 days.

Not yet measured (do not assume a figure): the duration of a full balance build at a given data volume; the time to activate a preserved cube.

8. Deployment, platform and security

8.1 Deployment and platform

• Deployment models: in the customer's own cloud account (AWS, Azure or Google Cloud), hybrid (application in cloud, data on premise), or fully on premise. The full feature set is available in every model.
• All data stays in the customer's environment. No SaaS dependency and no third-party processing.
• No internet connection is needed for summarisation, and there is no licence server. On-premise deployments can be air-gapped.
• Servers: Linux, with each service managed by systemd. Windows is not offered as a server platform (users use any browser on any desktop).
• Database: Microsoft SQL Server 2019 or later. The SQL is written in standard SQL where possible. MySQL holds only the logs of the two background engines.
• Application stack: Python (FastAPI) web applications; two Python services, the Summarisation Engine and the Email Reporting Engine (optional, typically on a separate server using the organisation's internal email).
• Hardware: one moderate, standard server. No in-memory licensing and no specialist hardware.
• Integration: file-based CSV extracts into a landing folder; no connection to the GL; read-only.
• Backup: the customer backs up a small set of tables (configuration, hierarchies, security, report definitions, watchlist history, variance comments, the audit log), held on their own filegroup; the large data tables are recreated from the GL by a full balance build after a restore.

8.2 Security model: the customer authenticates, Wevo authorises

• Wevo holds no user passwords in production. The customer's own sign-in (including any multi-factor authentication, password rules, joiners and leavers) identifies the person, through a reverse proxy that passes the signed-in name to Wevo. Wevo accepts that name only from the proxy's own address.
• Wevo then applies the user's security profile.
• Wevo refuses to start without its configuration and secrets; there are no built-in default passwords.

8.3 What a user can see

• Deny by default: no profile for a hierarchy means no access to it.
• A node profile gives a node and all of its descendants; a level profile gives a level and everything beneath it. Access therefore mirrors organisational responsibility.
• Every navigation (up, down, sideways, children, drilldown, export) is checked against the profile in the database. Changing a web address or a form value cannot reach a node outside the profile; such a node returns nothing at all.
• Promoting a changed hierarchy rebuilds the access paths of every profile that uses it, so security always follows the live structure.
• Email requests are checked against the sender's registered address, the user's token and the profile; reports go only to the registered user and can be password-protected.

8.4 Assurance

• No dynamic SQL in any production stored procedure, function or trigger, by design, removing a whole class of SQL-injection risk and simplifying code review.
• Every change made through the maintenance screens is audit-logged with the user's name and the time.
• Full source code is available for the customer's own review.
• Wevo is designed to operate within SOC 2 and ISO 27001 controlled environments.
• Not available today: an independent penetration test report, SOC 2 or ISO 27001 certification of the vendor, and a named, proven integration with a specific identity provider. The sign-in mechanism is generic (a trusted reverse proxy), so any identity provider that can sit in front of a web application can be used.

9. Implementation

Typical path, 6 to 10 weeks to live reporting:

1. Agree scope: entities, structures, years, reports, deployment model.
2. Install on the customer's Linux server and SQL Server database (development and production).
3. The customer builds the GL extract to the Wevo file specification, with Wevo's guide.
4. Migrate the hierarchies (typically 1 to 2 weeks), by batch input or in the hierarchy screens.
5. Summarise current and prior years through the current structure.
6. Set up security profiles and users; train users (typically 2 to 3 days).
7. Go live; schedule incremental extracts and the weekly full build.

Implementation is quoted as a fixed fee against agreed scope, with no day rates and no open-ended consultancy. A 90-day paid proof of concept runs Wevo against the customer's own GL extracts; its fee is credited in full against the first year if the customer goes ahead.

10. Commercial terms

10.1 Published fixed fees

• Single entity: GBP 5,000 a month, fixed. For one company, or a small group reporting under a single chart of accounts, with up to 500 cost centres. One organisation structure and one chart of accounts, single reporting currency, cloud, hybrid or on-premise, standard support.
• Group: GBP 7,500 a month, fixed. For multi-entity groups consolidating across several charts of accounts, currencies or reporting bases. Multiple entities and charts of accounts, multi-currency consolidation, unlimited cost centres and structures, point-in-time structure preservation, priority support.
• Institution: GBP 10,000 a month, fixed. For large groups, banks, insurers and government bodies with formal assurance and service-level requirements. Everything in Group, plus air-gapped on-premise deployment, agreed service levels, a security and assurance documentation pack, and a named support contact.

The fee is set by the size and complexity of the group (entities, charts of accounts, cost centres), not by users, data volume or server memory. Adding a hundred report recipients leaves the invoice unchanged.

10.2 Always included, at every tier

• Unlimited users and unlimited email report recipients.
• Development and production environments.
• Full source code under the Continuity Licence (the same grant at every tier).
• Updates and maintenance.

Never charged for: named-user or per-seat licences; memory, RAM or MIPS; data volume or row counts; optional modules or feature tiers; the non-production environment; additional structures or reporting years; preserved (dormant) structures.

10.3 How to buy

• Annual subscription billed monthly, 12-month minimum term; or an outright perpetual licence for buyers who prefer a capital purchase.
• Implementation: a fixed fee against agreed scope.
• Paid 90-day proof of concept on the customer's own data, credited in full against the first year.

11. Where Wevo sits among other kinds of software

• Against EPM and CPM suites (for example OneStream, Anaplan, IBM Planning Analytics, Oracle EPM): these combine planning, consolidation and reporting, typically at a significantly higher cost and with longer implementations. Wevo does not do planning or statutory consolidation; it delivers the management reporting, drilldown and comparatives at a fixed fee with unlimited users, and can sit alongside a planning tool by reporting its budgets and forecasts.
• Against GL reporting add-ins and spreadsheet-based reporting tools (for example insightsoftware Hubble or Spreadsheet Server): these are the nearest functional comparators for GL reporting with drilldown. Wevo's differences are the pre-calculated management structures, the separation of structure from data (as-is, as-was, Preserve Structure), and pricing that does not rise with users.
• Against BI tools: BI tools sit on a flat data model and need the hierarchy logic built into them. In Wevo the hierarchies are the data model and finance maintains them; Wevo's data can still feed a BI tool.
• Against the ERP's own report writer: Wevo works beside any GL, adds a management structure the chart of accounts may not hold, and survives reorganisations and ledger changes.
• Against a data warehouse built by IT: no warehouse project; finance owns the structures; figures are minutes behind the ledger rather than a night.

12. Accurate description

These points keep any description of Wevo exact:

• Near-real-time: minutes behind the GL, not instantaneous.
• Drilldown reaches the lowest level of detail held, the segment value x account intersection. Wevo holds accumulated values, not individual transactions.
• Users keep working during incremental loads. The weekly full balance build is scheduled out of hours and Wevo is not used while it runs.
• Wevo reports budgets and forecasts; it does not author, predict or plan them.
• Wevo is AI-ready: it collects structured, time-stamped financial data that a customer's own tools, including AI services, can analyse. Wevo itself contains and runs no AI model. Analyses flag patterns worth investigating; they are not fraud detection or control assurance.
• Restatement in Wevo is for management reporting, not statutory restatement.
• Preserve Structure is user-initiated: someone presses the button, before the change.
• A preserved structure cannot be amended, only deleted.
• The integration is file-based extracts that the customer builds and schedules, with Wevo's specification and guidance. There is no connection to the GL.
• Servers run Linux; the application database is SQL Server 2019 or later. There are no ports to other databases.
• Certifications: designed to operate within SOC 2 and ISO 27001 controlled environments; the vendor holds no such certification today.
• Email reports usually arrive within minutes of a request.
• Report formats: TXT, PDF, HTML and CSV. Supplied reports: trial balance and profit and loss.
• The period model is 16 periods plus an opening balance; there are no weekly periods.
• Debit and credit notation options: Dr, CrDr, brackets, trailing minus.

13. Questions and answers

Q: In one sentence, what does Wevo do? A: It turns a flat General Ledger into a live, navigable picture of the business: click any figure and see the detail beneath it, minutes behind the ledger, running entirely in your own environment.

Q: Does Wevo replace our ERP or GL? A: No. It is a read-only reporting layer fed by extracts. The GL stays the system of record and Wevo cannot change it.

Q: Which ledgers does it work with? A: Any GL that can produce structured flat-file extracts: SAP, Oracle, Microsoft Dynamics, Sage, mainframe ledgers and others. Several ledgers can feed one group view.

Q: Do we need to connect Wevo to our GL? A: No. There is no connection. Your GL writes extract files to a landing folder; Wevo reads them. This removes a whole integration and security project.

Q: How current is the data? A: Minutes behind the GL, depending on how often your extract runs; extracts every 15 to 30 minutes are typical. Users keep working during these updates.

Q: How fast is drilldown? A: Typically under a second, because every roll-up is calculated in advance.

Q: We reorganise every year or two. What happens to our comparatives? A: Every year is read through today's structure automatically (as-is), so comparatives stay like for like with no restatement. If you also need to see the past exactly as it was reported, preserve the structure before each change.

Q: Can we reproduce last year's figures exactly as we reported them, after a reorganisation? A: Yes, if the structure was preserved before the change. Preserve Structure keeps the exact structure for under 1 MB; activate it for a year and the next full build reproduces the figures from the same leaf-level data. If it was not preserved before the change, the old arrangement cannot be copied afterwards, which is why routine monthly preservation is recommended.

Q: Can we quantify what a restructure did to our numbers? A: Yes. Report the same year through the old and the new structure side by side; the difference is the restructure effect.

Q: Does Wevo freeze prior years? A: No. Every allocated year stays synchronised with the GL, so prior-year adjustments and audit corrections appear like any other posting.

Q: Can we have prior-year comparatives at go-live? A: Yes. Prior years already on the GL can be summarised through the current structure from day one.

Q: Who maintains the hierarchies? A: Finance, in a development environment, with validation, promote and lock, and an audit log. Changes go live at the next full build.

Q: Does it handle multiple entities and currencies? A: Yes: multi-entity, multi-currency consolidation for management reporting, with base and source currency views. Statutory consolidation is outside its scope.

Q: Can we compare actuals with budgets and forecasts? A: Yes, side by side at every node, through the same hierarchies, with the variance of the actual shown on hover. Several budget versions can be held. Wevo reports the budgets and forecasts you load; it does not produce them.

Q: Is Wevo a planning or forecasting tool? A: No. It reports plans made elsewhere, alongside actuals, through the same structures. It works well beside a planning tool.

Q: Can managers explain variances in Wevo? A: Yes, in short form: authorised users add variance comments of up to 100 characters to a node pair, recorded with the user and the time.

Q: How many users can we have, and what does it cost to add more? A: Unlimited users and unlimited report recipients, at no extra cost, at every tier.

Q: What does Wevo cost? A: Three published fixed monthly fees: GBP 5,000 (Single entity), GBP 7,500 (Group) and GBP 10,000 (Institution). Implementation is a fixed fee against agreed scope.

Q: Can we try it first? A: Yes. A live online demo shows Wevo with a fictitious bank's ledger. A 90-day paid proof of concept runs it on your own GL extracts, with the fee credited against the first year if you go ahead.

Q: How long does implementation take? A: Typically 6 to 10 weeks to live reporting, including hierarchy migration (typically 1 to 2 weeks) and user training (typically 2 to 3 days).

Q: Where does it run? A: In your own environment: your cloud account, hybrid or on premise, on Linux servers with SQL Server 2019 or later. No internet connection is needed, and it can run air-gapped.

Q: Is our data sent anywhere? A: No. All data stays in your environment. There is no SaaS service and no third-party processing.

Q: How do users sign in? A: Through your own sign-in, including your multi-factor rules. Wevo holds no user passwords in production; it applies each user's security profile.

Q: Can a user see figures outside their responsibility? A: No. Access is deny-by-default and every navigation is checked against the user's profile in the database. A node outside the profile returns nothing.

Q: Is Wevo certified (SOC 2, ISO 27001)? A: No. It is designed to operate within SOC 2 and ISO 27001 controlled environments, runs entirely in your estate, contains no dynamic SQL in its production code and comes with its full source code for review.

Q: What if the vendor goes out of business? A: You already hold the full source code under the Continuity Licence, which lets you keep and continue the product. This is stronger than escrow.

Q: Does Wevo use AI? A: Wevo runs no AI model. It is AI-ready: the watchlist builds a time-stamped history of key figures that your own BI or AI tools can analyse.

Q: Can we see individual journals? A: Wevo drills to the lowest level held, the segment value x account intersection, as accumulated values. Individual journal lines remain in the GL.

Q: Is there downtime? A: Not during incremental loads, which run while users work. The weekly full balance build runs out of hours (for example overnight on a Saturday) and Wevo is not used while it runs.

Q: How do people get reports without logging in? A: Authorised users receive a request form by email, choose their parameters and send it; the report returns by email, usually within minutes, as TXT, PDF, HTML or CSV, optionally password-protected.

Q: What reports come with Wevo? A: Trial balance and profit and loss. Other reports can be built for you, and you may add your own.

Q: How big a structure can Wevo handle? A: Up to 20 levels per hierarchy, no limit on nodes; 25,000 organisational and 5,000 account nodes have been demonstrated.

Q: Can Wevo offload reporting from our mainframe? A: Yes. The reporting workload moves to one ordinary server; the mainframe GL stays as the system of record. Wevo itself began on IBM mainframes in Tier-1 banking.

Q: What does IT have to run? A: One Linux server with SQL Server, two background services, scheduled extracts from the GL, and a backup of a small set of tables. No GL connection to build or secure.

Q: Can we brand it or add our own reports? A: Yes. You may re-brand the screens for internal use and add your own reports; your additions sit outside support.

Q: How is Wevo different from OneStream or other EPM suites? A: Wevo is not a planning or statutory consolidation suite. It provides the management reporting, drilldown and reorganisation-proof comparatives at a fixed fee with unlimited users, and can report the budgets and forecasts an EPM or planning tool produces.

Q: How is it different from a BI tool? A: In Wevo the management hierarchies are the data model and finance maintains them; figures are pre-calculated at every node. A BI tool needs that logic built into it.

Q: What is the single most unusual thing about Wevo? A: Structure and data are kept separate. That is what makes like-for-like comparatives automatic, makes exact reproduction of past reporting possible, and makes a reorganisation cost nothing in reporting terms.

14. Planned development (not available today)

Status: planned. Not available in the current product, with no committed release date. Nothing in this section should be described as an existing capability.

Node pair triggers: rules that a user would define on watched node pairs, with their own calculation, such as an actual against budget or forecast beyond a limit, a change since the previous snapshot, or a balance that stays outside a range. When a rule is true, Wevo would record an event in a table for the customer to act on, for example by notifying the right people. The design is under discussion. It builds on the watchlist (4.11) and on actuals, forecasts and budgets side by side (4.3).

15. Contact and next steps

• Website: https://www.wevo.co.uk
• Live demo: https://www.wevo.co.uk/demo.html (a working Wevo with a fictitious bank's ledger behind it)
• Request a demo on your own scenario: https://www.wevo.co.uk/contact.html
• Email: info@wevo.co.uk
• Pricing: https://www.wevo.co.uk/pricing.html
• Documents (Business Introduction, presentation, guides): https://www.wevo.co.uk/resources.html

Wevo GL Analytics is a product of Professional Software Ltd, registered in England and Wales, company number 01951252.