brd
Caesar — Business Requirements Document, Phase 1
Section titled “Caesar — Business Requirements Document, Phase 1”Source of truth. Faithful markdown rendering of
Caesar_BRD_Phase1.docx(Draft v0.2). Original preserved atattachments/Caesar_BRD_Phase1.docx. MocX Group system of record — built in-house, on the road to NetSuite OneWorld.
| Document owner | Office of the CEO / CPO (Osita) — sponsor: Steven (CFO); delivered by Engineering |
| Status | Draft v0.2 — for internal alignment |
| Classification | Confidential — internal |
| Scope | Phase 1 — Caesar replaces Zoho as system of record. Later phases mature toward the NetSuite OneWorld destination. |
1. Purpose and how to read this document
Section titled “1. Purpose and how to read this document”Caesar is MocX’s finance platform — a system we build ourselves, in the same family as Hermes, Polaris, Atlas and Argus, on the same stack. This document specifies Phase 1: standing Caesar up as our system of record in place of Zoho Books.
NetSuite OneWorld is the destination, not the build. We are not licensing or configuring OneWorld now — at two entities that would be premature and overweight. Instead we build Caesar lean and deliberately shaped along OneWorld’s architecture, so that as clusters multiply and SPVs are stood up, Caesar matures toward OneWorld-class capability and the eventual move onto OneWorld itself is a clean lift rather than a rebuild.
Phased on purpose. Phase 1 is parity plus foundation: take the books off Zoho, get the entity hierarchy and the dimensional spine right (the two things expensive to retrofit), and stand up the real-time command centre. Later phases mature Caesar toward the destination and are sketched at the end, explicitly out of scope for the first build.
Guiding instruction: don’t gold-plate, and don’t build structures we’d later have to unwind. Where a capability is real but not yet needed, it is parked in the roadmap. Where a foundation decision is expensive to change, it is made now and made OneWorld-shaped.
2. What Caesar is
Section titled “2. What Caesar is”Caesar is the finance member of the MocX platform family — the counterpart to Hermes (fleet telemetry), Polaris (people), Atlas (case management) and Argus (field intelligence). Where those systems own operational truth, Caesar owns financial truth, and in Phase 1 it becomes the system of record.
Caesar has two layers, and the distinction drives everything below:
| Layer | What it is |
|---|---|
| Ledger core (system of record) | An in-house double-entry general ledger with its sub-ledgers — payables, procurement, fixed assets, group roll-up — built on the MocX stack (the same Postgres foundation as Hermes, Polaris, Atlas and Argus). These are the audited books: financial events recorded once, cleanly, under a governed chart of accounts. |
| Command centre | The real-time situational view on top — fixed-asset register, swap revenue as it accrues, money in bank, liabilities, open requisitions, consolidated position. It blends booked financials from the ledger with live operational feeds from Hermes and the billing stack. |
The destination. Caesar’s architecture is modelled on NetSuite OneWorld — the subsidiary tree, the segment dimensions, summarised journals, the intercompany model. OneWorld is where Caesar is headed: as scale, audit and lender complexity grow, Caesar either reaches OneWorld-class capability in-house or migrates onto OneWorld itself. Building OneWorld-shaped now is what keeps that road open and the eventual cutover clean.
Core architectural principle. The ledger takes summarised journals, never raw operational volume. Ten thousand riders and their swaps never hit the GL as individual lines — Hermes and the billing system aggregate them into daily revenue journals per cluster. The command centre’s “real-time swap revenue” is the operational feed shown alongside the booked position, not a ledger of every swap. This is what keeps Caesar fast at scale, and it is the same reason Zoho didn’t break on transaction count — it breaks on entity structure, which Caesar is built to handle.
3. Design principles
Section titled “3. Design principles”- Lift, don’t reinvent. Phase 1 replicates the accounting we run today in Zoho. We do not redesign finance processes during the move to a new system of record.
- Build OneWorld-shaped. Caesar’s data model mirrors OneWorld’s — subsidiary tree, segments, summarised journals, intercompany. We don’t invent structures we’d have to unwind to reach the destination; maturation is a lift, not a rebuild.
- Get the un-retrofittable things right now. The subsidiary hierarchy and the dimensional spine anticipate SPVs and multi-cluster from day one, even though most are not yet populated. Everything else can phase.
- Keep operational granularity out of the ledger. Source systems hold the detail; the ledger holds summarised journals. The command centre reunites them for viewing.
- Audit-grade from day one. These are the books of record and they front the Series A audit. Double-entry integrity, immutable posted journals, period locking and a full audit trail are non-negotiable primitives, not later additions.
- One financial truth, reconciled to the model. Consolidated, entity and cluster positions all fall out of the same governed data — no parallel spreadsheets — and account structure, asset classes and unit economics tie back to
MocX_Consol_FinModel_v22.
4. Current state — the Zoho Books baseline we are replacing
Section titled “4. Current state — the Zoho Books baseline we are replacing”Phase 1 is anchored to what Zoho does for us now, so taking over the books is a known quantity rather than an open-ended build. The table states the baseline at the level we are confident in; the first task is to validate it against the live Zoho configuration before cut-over.
Note: this is a starting assumption to be confirmed against the actual Zoho orgs, not an audited inventory.
| Area | Today in Zoho Books | In Caesar Phase 1 |
|---|---|---|
| Entities | Separate orgs for MocX Smart Technologies Inc. (Delaware) and MocX Smart Technologies Limited (Nigeria); consolidation done outside the system. | Both modelled as subsidiaries under one Caesar instance with a native group roll-up. |
| Chart of accounts | Two independent charts, manually reconciled. | One governed group COA with local extensions; mapped from Zoho at migration. |
| Payables / suppliers | Vendor bills and payments, light PO use. | Full AP plus requisition-to-PO approval workflow. |
| Revenue | Manual / summarised entries for swap income. | Summarised daily journals posted by cluster from billing / Hermes. |
| Banking | Bank feeds and reconciliation per org. | Multi-currency bank feeds and reconciliation per subsidiary. |
| Fixed assets | Minimal / spreadsheet register. | Native fixed-asset sub-ledger seeded with the deployed fleet. |
| Consolidation & FX | Spreadsheet roll-up, manual elimination and translation. | Native two-entity roll-up with parent/opco elimination; automated multi-entity elimination matures toward the destination. |
5. Target entity and subsidiary architecture
Section titled “5. Target entity and subsidiary architecture”This is the foundation that cannot be cheaply changed later, so it is fully specified now even though only the first two operating subsidiaries are populated at go-live. Caesar represents the group as a subsidiary tree with a top elimination entity — modelled on OneWorld’s structure — so SPVs slot in as new subsidiaries under the Nigerian operating company without re-architecting anything.
| Subsidiary | Functional ccy | Role |
|---|---|---|
| MocX Group (Elimination) | USD | Top-of-house roll-up and elimination entity. Group reporting currency is USD. |
| MocX Smart Technologies Inc. | USD | Delaware C-corp parent. Holds equity, US-level costs, investor-facing cap structure. |
| MocX Smart Technologies Ltd. | NGN | Nigerian operating company. Core operations: retrofit, swap revenue, procurement, the deployed fleet. |
| AssetCo SPV (template — designed-in, not yet populated) | NGN | Bankruptcy-remote vehicle template for ringfenced clusters under senior lending. Structure, intercompany flows and reporting are configured but dormant until the first SPV closes. |
Multi-currency posture. Group reports in USD; the operating company is functionally NGN; we carry CNY transaction exposure through the Telpo supply and financing relationship. Phase 1 handles transaction-level FX and a basic group roll-up. Automated elimination and a formal translation policy mature toward the destination (roadmap, §13).
6. The dimensional spine — segments and chart of accounts
Section titled “6. The dimensional spine — segments and chart of accounts”If the entity tree is the skeleton, the segments are the nervous system. Getting them right is what lets us slice a cluster P&L or an SPV-level statement without rebuilding anything — the single most important design choice for “build it so it grows.” Mirroring OneWorld’s segment model, every financial line in Caesar carries four classifications plus the entity:
| Segment | Captures | Why it matters |
|---|---|---|
| Subsidiary | Legal entity / SPV | Statutory books, roll-up, SPV ringfencing and lender reporting. |
| Location | Cluster, then station within cluster (e.g. Sango-Ota → Toll Gate) | Cluster-level P&L and asset attribution; the unit of SPV ringfencing. |
| Class | Business line (Swap subscription, KAAG, future lines) | Revenue and margin by product without new accounts. |
| Department | Function (Retrofit Ops, Battery Production, Supply Chain, R&D, G&A…) | Cost ownership and the OKR / bonus-band framework. |
Chart of accounts. One lean, IFRS-aligned group COA with local extensions for Nigerian statutory needs, mapped from the two Zoho charts at migration and reconciled to FinModel_v22 account groupings. The COA stays deliberately short and analytical detail lives in the segments above — a wide COA is the classic way these systems rot.
7. The Caesar command centre — real-time financial situation
Section titled “7. The Caesar command centre — real-time financial situation”This is the view you asked for: the single pane where the fixed-asset register, swap revenue, cash, liabilities and requisitions are all live. Each domain has a defined source of truth and refresh cadence, so we never argue about which number is real. “Real-time” means the booked financial position from the ledger, overlaid with the live operational feed where one exists.
| Domain | What it shows | Source of truth | Cadence |
|---|---|---|---|
| Swap revenue | Month-to-date booked revenue plus today’s accruing swaps, against the SRRR expectation, by cluster and mesh. | Hermes / billing (live) + ledger (booked) | Intraday |
| Money in bank | Multi-currency cash balances by subsidiary and account; group cash in USD. | Bank feeds → Caesar | Daily (feed) |
| Liabilities | Telpo facility, asset-finance debt, AP, deferred tail; principal, accrued interest, next payment. | Ledger + maintained debt schedules | On booking |
| Fixed-asset register | Deployed trikes and packs at net book value, by cluster / SPV, with collateral status. | FA sub-ledger, fed by Hermes deployment events | Daily |
| Requisitions | Open requisitions and POs, committed-but-unbilled spend, by entity and cluster. | Caesar procurement | Real-time |
| Receivables / collections | Rider billing and collections, tied to SRRR realisation. | Billing + ledger | Daily |
| Consolidated position | Group P&L / balance-sheet snapshot, D:E ratio, covenant headroom. | Caesar roll-up | Period + on-demand |
Delivery. Phase 1 delivers the command centre through Caesar’s own dashboards and saved views for the booked domains, plus a small operational overlay (swap revenue, deployment events) fed from Hermes. The discipline now is that every tile has one agreed source — not that it is beautiful.
8. Functional requirements — Phase 1
Section titled “8. Functional requirements — Phase 1”Specified at the level engineering needs to scope the build. This is the “what,” not the “how.”
8.1 Ledger core, close and roll-up
Section titled “8.1 Ledger core, close and roll-up”- Double-entry general ledger built in-house, with the non-negotiable primitives of a system of record: double-entry integrity, immutable posted journals, period locking, and a complete audit trail on every posting.
- The subsidiary tree and segments of sections 5 and 6.
- Period close per subsidiary and a native group roll-up with parent/opco elimination.
- Summarised-journal posting from source systems; the ledger holds no raw operational volume.
- Automated multi-entity elimination and a formal FX translation policy mature toward the destination — Phase 1 covers the two current entities.
8.2 Payables, procurement and requisitions
Section titled “8.2 Payables, procurement and requisitions”- Vendor master migrated from Zoho; Telpo and component suppliers set up with terms.
- Requisition → purchase order → bill flow with an approval matrix (amount- and entity-based routing).
- Open requisitions and committed spend surfaced to the command centre.
- Phase 1 keeps approvals and two-way match; full three-way match and receipt-level controls mature later.
8.3 Revenue posting
Section titled “8.3 Revenue posting”- Daily summarised swap and KAAG revenue journals posted by cluster from the billing / Hermes integration.
- Riders remain in the billing system, not as Caesar customers — the ledger sees aggregated revenue and collections only.
- SRRR stays owned by the operational stack; Caesar shows the booked-revenue reconciliation against it.
- IFRS-15 multi-element revenue automation (subscription + KAAG tiering) matures later.
8.4 Banking and cash
Section titled “8.4 Banking and cash”- Bank feeds per subsidiary across NGN and USD accounts; automated reconciliation.
- Group cash position in USD on the command centre.
8.5 Fixed assets and the fleet register
Section titled “8.5 Fixed assets and the fleet register”Near-core for MocX: the fleet is both the operating asset base and the collateral behind every asset-finance facility, so the register cannot be a spreadsheet.
- Asset sub-ledger seeded with the deployed fleet (trikes and packs) by cluster and subsidiary.
- Capitalisation triggered by Hermes deployment events; straight-line depreciation by asset class, reconciled to FinModel_v22.
- Collateral / SPV tagging on each asset so ringfenced pools are reportable from day one.
- IFRS-16 lease accounting, componentisation, and disposal / second-life handling mature later.
8.6 Inventory — kit and pack lifecycle
Section titled “8.6 Inventory — kit and pack lifecycle”- Telpo kits, battery packs and components received into inventory against POs.
- On deployment, inventory converts to a capitalised fixed asset — the single most MocX-specific flow in the system.
- Demand planning and manufacturing / WIP stay out until in-house pack production scales (a known future BU trigger).
8.7 Liabilities and facility tracking
Section titled “8.7 Liabilities and facility tracking”- Debt and facility schedules (Telpo facility, asset-finance overlays, the deferred tail) maintained with principal, interest accrual and amortisation.
- D:E and covenant-relevant figures exposed to the command centre.
8.8 Intercompany
Section titled “8.8 Intercompany”- Parent ↔ operating-company flows (funding, recharges) with elimination at the group roll-up.
- Operating-company ↔ SPV servicing-fee and asset-transfer flows are configured but dormant until the first SPV closes.
8.9 Nigerian tax
Section titled “8.9 Nigerian tax”Because we own the system, there is no third-party localisation to work around — Caesar implements the Nigerian indirect-tax requirements directly as part of the build: VAT and WHT capture and reporting, and readiness for FIRS e-invoicing. We build exactly the tax logic the Nigerian opco needs and the extracts its statutory filings require, rather than bending a generic engine to fit.
9. Integration architecture
Section titled “9. Integration architecture”Caesar is the financial hub; the operational systems remain the source of their own truth and feed Caesar summarised data. The Phase 1 integration set is small and deliberate.
| From | What flows to Caesar | Direction / shape |
|---|---|---|
| Hermes (telemetry) | Daily summarised swap revenue by cluster; asset deployment events that trigger capitalisation; live swap feed for the command centre. | Inbound, summarised + event |
| Billing system | Rider billing and collections summaries; KAAG revenue. | Inbound, summarised |
| Polaris (HRIS) | Payroll journals. | Inbound, summarised |
| Banks | Transaction feeds for reconciliation. | Inbound, feed |
Principle restated: no integration pushes raw per-event volume into the ledger. Granularity stays upstream; Caesar receives aggregates and references.
10. Reporting
Section titled “10. Reporting”Beyond the live command centre, Phase 1 must produce, from the same governed data, the recurring outputs the business already needs:
- Consolidated and entity-level P&L, balance sheet and cash flow.
- Cluster-level P&L via the Location segment.
- Fixed-asset / collateral register by SPV pool (groundwork for lender reporting).
- The monthly board pack, sourced without spreadsheet reconciliation after roll-up.
11. Data migration and cut-over
Section titled “11. Data migration and cut-over”- Validate the current Zoho configuration (§4) and finalise COA mapping.
- Migrate masters (vendors, the limited customer set, COA) and opening balances per entity.
- Seed the fixed-asset register from the deployed fleet with correct in-service dates and net book values.
- Carry open AP and AR balances; agree a clean period-end cut-over date.
- Run a parallel close for one period before retiring Zoho as the system of record.
12. Roles, access and controls
Section titled “12. Roles, access and controls”- Role-based access with segregation of duties between requisition, approval, payment and posting.
- Approval matrices by amount and entity for payables and journals.
- Audit trail on all postings — a hard requirement given the Series A audit ahead.
13. Maturation roadmap — toward the OneWorld destination
Section titled “13. Maturation roadmap — toward the OneWorld destination”Phase 1 is what this document specifies. Later phases mature Caesar toward OneWorld-class capability, mapped against the financing arc — and the destination itself is an explicit decision, not a default.
| Phase | Scope | Trigger / timing |
|---|---|---|
| Phase 1 — Caesar = system of record | Take the books off Zoho: double-entry ledger, two entities + group roll-up, AP & requisitions, summarised revenue, bank rec, fixed-asset register, inventory→asset flow, command centre, Nigerian tax. OneWorld-shaped foundation laid; SPV machinery designed-in but dormant. | Now — ahead of the first AssetCo SPV closing. |
| Phase 2 — toward OneWorld: SPV & lender grade | Activate SPV subsidiaries; automated intercompany elimination + FX translation policy; fixed assets at scale + IFRS-16; three-way match; lender / covenant reporting; multi-book if a separate IFRS / US-GAAP book is needed. | First senior-lending SPV (SixPoint / Arcadia) — Pre-Series A window. |
| Phase 3 — OneWorld-class | Full automated multi-entity consolidation across many SPVs; advanced revenue recognition; planning / budgeting; deeper procure-to-pay. | Series A and the move to ~50k tricycles. |
| Destination — the OneWorld decision | With Caesar at OneWorld-class maturity, take the explicit build-vs-adopt call: continue on the in-house platform or migrate onto NetSuite OneWorld itself. Keeping Caesar OneWorld-shaped throughout makes either path clean. | When scale, audit and complexity justify the enterprise platform. |
14. Explicitly out of scope for Phase 1
Section titled “14. Explicitly out of scope for Phase 1”Naming these protects the build from creep:
- CRM and sales-force automation.
- Payroll execution (stays in Polaris; only journals flow in).
- Automated IFRS-15 multi-element revenue recognition.
- IFRS-16 lease accounting and asset componentisation.
- Demand planning, manufacturing / WIP, e-commerce.
- Live SPV books and lender reporting (configured, dormant).
- Automated multi-entity elimination beyond the two-entity parent/opco roll-up.
15. Assumptions and open decisions
Section titled “15. Assumptions and open decisions”These shape the build. Recommendations noted; confirm before engineering scopes Phase 1.
| Decision | Options | Recommendation |
|---|---|---|
| Ledger-core approach | Build the double-entry engine from scratch, or stand it on a proven embeddable ledger / accounting library and build MocX logic on top. | Stand on a proven ledger primitive for double-entry integrity; don’t hand-roll the riskiest part. Confirm with engineering. |
| Entities at go-live | Two current entities only, or model the first SPV in from day one. | Two current operating subsidiaries live; SPV structure configured but dormant. |
| Accounting books | Single book in Phase 1, or multi-book (IFRS + US GAAP) from the start. | Single book in Phase 1; revisit multi-book in Phase 2 when the SPV and audit picture firms up. |
16. Build considerations
Section titled “16. Build considerations”- Caesar is built by MocX engineering, in the same family and on the same stack as Hermes, Polaris, Atlas and Argus — not a vendor ERP rollout.
- The hard requirement is accounting correctness: the ledger core must be audit-grade from day one because it fronts the Series A audit. Finance ownership (Steven, CFO) pairs tightly with engineering throughout.
- Indicative timeline to a usable Phase 1 to be set with engineering once the ledger-core approach (build vs embed) is decided.
- Sponsor: Steven (CFO); business owner: Office of the CEO / CPO; delivered by Engineering.
- Treated as both a fundraising-enabling investment (audit-readiness, lender reporting) and a strategic asset — Caesar’s OneWorld-shaped data model is the bridge to the destination.
End of document — Caesar BRD Phase 1, Draft v0.2. Prepared for internal alignment; figures and structure to be confirmed against the live Zoho configuration and FinModel_v22.