eSevo wordmark Premium near-black sans grotesque eSevo wordmark on a transparent background.
Request the brief
Navigate

Esevo — controlled financial operations
A product of 18222916 Canada Inc.

Accounting that can prove itself.

Esevo is a ledger-first ERP built on one rule: nothing is posted that cannot be evidenced. Entries move from proposed to authorized to posted — and once posted, they do not change.

Request the architecture brief See how a posting happens
Journal entry Controlled workflow
Proposed
Bank feed rule · BR-114 09:14:02
Authorized
Controller · dual approval 11:41:37
Posted
Append-only · period 2026-09 11:41:38
DebitCredit
—18,420.00
18,420.00—
JE-2026-09-0417 CAD · functional CAD

01 — Ledger first

The ledger is the system, not a reporting layer

Modules do not hold their own truth. Payables, receivables and revenue write into one double-entry ledger under authorization, so the statements and the subledgers cannot drift apart.

02 — Evidence, not assertion

Every posted entry carries its basis

Actor, timestamp, the rule that produced the proposal and the document it came from are stored with the entry — not reconstructed from logs at audit time.

03 — Jurisdiction aware

Policy is modelled where regimes disagree

Canadian, US, UK and EU treatment is expressed as data rather than code branches, including the places where those requirements genuinely conflict.

Intake

Everything arrives as a proposal

Bank feeds, supplier files, webhooks and manual schedules all enter the same lane. Whatever the channel, nothing crosses the authorization boundary on its own.

Intake stream · 28 transaction types Operational intake
Received Proposed entry

The intake queue and authorization card show how governed financial work moves from source evidence through review and approval.

The catalog

41 capabilities. One ledger underneath all of them.

This grid is generated at build time from the product capability catalog and fails the build if it diverges from it. Status is published exactly as the catalog records it.

Ledger core

09

  • General ledger

    Append-only double-entry ledger with immutable posted entries.

    Available

  • Chart of accounts engine

    Versioned account structures with effective-dated changes.

    Available

  • Journal authorization

    Entries move proposed to authorized to posted, never in place.

    Available

  • Multi-entity structures

    Entity hierarchies with per-entity books and shared masters.

    Available

  • Multi-currency

    Transaction, functional and presentation currency held separately.

    Available

  • Functional currency locking

    Functional currency fixed per entity and period, not per posting.

    Available

  • FX revaluation

    Period-end revaluation with rate provenance retained on the entry.

    Available

  • Dimensions and segments

    Typed analytical dimensions validated at posting time.

    Available

  • Multi-book accounting

    Parallel accounting books with governed mappings, policies and reporting bases.

    Available

Transaction cycles

15

  • Accounts payable

    Supplier invoices, approvals and payment proposals against the ledger.

    Available

  • Accounts receivable

    Customer invoicing, application of receipts and aged balances.

    Available

  • Bank reconciliation

    Statement matching that produces reviewable proposed entries.

    Available

  • Cash management

    Cash positions, movements and forecasts linked to bank and ledger evidence.

    Available

  • Treasury management

    Governed liquidity, funding and treasury workflows across entities and accounts.

    Available

  • Order management

    Orders, fulfilment events, invoicing and accounting outcomes kept in one traceable flow.

    Available

  • Purchase order management

    Purchase requests, approvals, commitments, receipts and invoices connected to payables.

    Available

  • Subscription billing

    Recurring billing schedules, amendments and revenue evidence governed over time.

    Available

  • Account allocation automation

    Rule-based allocations with reviewable drivers, calculations and resulting entries.

    Available

  • Document capture

    Extraction from source documents that yields proposals, not postings.

    Available

  • Fixed assets

    Asset registers with schedule-driven depreciation runs.

    Available

  • Revenue recognition

    Performance-obligation schedules recognised on their own calendar.

    Available

  • Deferrals and accruals

    Deferral and accrual schedules tied to their originating documents.

    Available

  • Intercompany

    Paired intercompany postings with elimination candidates identified.

    Available

  • Tax determination

    Jurisdiction rules resolved at document level and retained as evidence.

    Available

Close and reporting

06

  • Period close control

    Soft and hard close states enforced by the ledger, not by convention.

    Available

  • Consolidation

    Group reporting with ownership, translation and elimination layers.

    Available

  • Financial reporting

    Statements built from the ledger, traceable back to source entries.

    Available

  • Reporting and analytics

    Financial and operational analysis across entities, periods, accounts and dimensions.

    Available

  • Flux analysis

    Period-over-period movement explained down to contributing entries.

    Available

  • Budgeting and forecasting

    Budget versions compared against actuals on the same dimensions.

    Available

Control and evidence

06

  • Audit trail

    Every state change recorded with actor, time, reason and prior value.

    Available

  • Segregation of duties

    Role conflicts declared and enforced at the authorization boundary.

    Available

  • Approval workflows

    Thresholded approval paths that produce a signed authorization record.

    Available

  • Anomaly review

    Flagged entries routed to a human reviewer before authorization.

    Available

  • Retention and residency

    Data residency and retention policies applied per entity and record class.

    Available

  • Financial workflows

    Configurable finance processes with accountable owners, approvals, evidence and deadlines.

    Available

Automation and connectivity

05

  • Accounting integrations

    Controlled ingestion and export patterns for financial systems and source records.

    Available

  • Implementation and migration

    Structured configuration, mapping, validation and cutover evidence for adopting Esevo.

    Available

  • Automated accounting

    Deterministic rules and governed proposals reduce repetitive accounting preparation.

    Available

  • AI accounting intelligence

    Evidence-linked assistance for classification, matching, investigation and explanation.

    Available

  • Developer API and file exchange

    Programmatic and file-based interfaces for approved data movement and workflow integration.

    Available

The evidence seam

Three states. One direction. No edits behind the line.

Automation is allowed to propose. It is not allowed to post. The seam between those two things is where the control lives.

STATE 01

Proposed

Imports, bank feeds, document extraction and models produce proposals. A proposal states its basis and its confidence. It touches no balance and appears in no statement.

STATE 02

Authorized

A person holding the right role — and not holding a conflicting one — authorizes. The authorization is recorded as its own signed, timestamped fact, separate from the entry it approves.

STATE 03

Posted

The entry is written append-only into a locked period. Corrections are made by further entries that reference what they correct. History is never rewritten.

Architecture

Decisions we are not planning to revisit

These are the constraints the engine is built against. They are load-bearing, and they are the reason several convenient features are not on the roadmap.

01

Balance is enforced by the database

Double entry is a constraint in the storage layer, not a check in application code that a future service can forget to call.

02

Functional currency is locked per entity and period

Transaction, functional and presentation currency are three separate stored facts. The functional currency cannot be reinterpreted after the fact to make a number look better.

03

Effective dating instead of mutation

Accounts, rates, policies and dimensions change by adding a new effective-dated version. Prior periods continue to resolve against what was true then.

04

Policy is data, reviewed by accountants

Recognition, tax and consolidation rules live in reviewable policy records rather than in branches of code, so a qualified reviewer can read what the system will do.

05

Models propose, people authorize

There is no configuration in which a model posts to the ledger on its own. The authorization boundary is architectural, not a setting.

06

Erasure and immutability are reconciled deliberately

Personal data is held apart from ledger facts so that a subject-rights request can be honoured without rewriting an accounting record. This is a design constraint, not an afterthought.

Architecture brief

Read the engineering position, not a sales deck

The detailed system brochure covers Esevo's ledger model, reconciliation and close, Canadian operations, controls, integration architecture, implementation, and evaluation criteria.

Submit the form and we will email the brochure immediately. We use your details only to deliver the document and respond to your request; this does not subscribe you to marketing.

Entity count, jurisdictions, the system you would be moving from, and what has to be true for you to move.

Protected by Cloudflare Turnstile.

Or write to architecture@esevo.com.

Esevo

If the ledger cannot prove it, it did not happen.

That is the whole product argument. Everything else is scheduling.

Request the architecture brief Review the catalog

Connected financial operations

Connect the systems your finance team already uses.

Bring source records into one governed accounting flow, then return approved outputs and reconciliation evidence to the systems that execute the work.

Representative connection targets across banking, payroll, data, payments and card networks. All product names and marks belong to their respective owners; inclusion does not imply endorsement or partnership.