Skip to main content
Financial services

A financial figure is run by its trace not by the visible balance

We implement operating systems for financial and accounting entities: books, reconciliations and a monthly close; contracts, instalment schedules and collection; a client and document register; e-invoicing; and an audit trail for every movement — sized to your work: an accounting practice needs a disciplined close per client, an instalment business needs a contract, a schedule and collection, an investment manager needs an asset, contract and recorded-return register rather than a promised one, and a payment service needs settlement and a trace per movement. What they share: what is not recorded with its trace cannot be proven — not to an auditor, not to a regulator, not to a client in a dispute.

Request an operations assessmentSee the operation types
  • Four operation types, four scopes
  • We are not a licensed financial institution
  • No investment advice and no Shariah ruling
  • No promised profit, return or collection rate
  • No card data through our systems

Direct answers

The questions asked first

Are you a licensed financial institution or a payment service provider?

No. We are a systems company: not a bank, a finance company, a payment service provider or an investment firm, holding no licence from any regulator, representing none and handling no licensing procedures. What we do is build the system that runs and documents the operation, while licensing, regulatory compliance and the responsibility for regulatory reporting remain with the licensed entity — and we say so at assessment stage, before the contract rather than after it.

Do you guarantee profit, a return or a collection rate?

No. A return is set by the market, the asset, risk and timing, and collection is set by clients’ ability, your procedures and the market — neither is controlled by an administrative system. What we do commit to is that every contract, instalment schedule, collection movement, expense and actual return is recorded with its conditions, and that ageing and reconciliations are read from matching figures rather than estimates. Anyone guaranteeing a return or a collection rate in this sector guarantees what they do not own, and we do not offer it.

Do you provide financial advice or Shariah rulings?

No. We give no investment, financial, tax or statutory accounting advice, and we issue no Shariah ruling or opinion on the permissibility of a product or a financing structure — that belongs to your Shariah advisor, your statutory accountant and your auditor. Our role is to build the system that records what has been agreed and produces its documents; if the product itself is subject to a Shariah or regulatory opinion, the decision is not ours and we do not build on an assumption of our own.

What usually stops finance systems projects?

Three things we see repeatedly, none of them technical: non-unified master data — accounts, clients and cost centres shaped differently by each user, making a fast close impossible; deferred bank reconciliations, so differences accumulate until their cause can no longer be found; and broad permissions with no audit trail, so who edited an entry or approved a payment is unknown. That is why we start with master data, reconciliation, the audit trail and permissions, before any promise of a report or a dashboard.

Context

Why this sector is different in the Kingdom

Four regulatory and operational realities impose strict requirements on the system — with no market figures and no targets.

The financial sector sits within Vision 2030 priorities

Developing the financial sector is one of the Vision 2030 axes, with a general direction towards digital service and greater financial inclusion — context that explains the demand for documentation and reporting, while we publish no numbers or targets, because they are not ours and we cannot verify them.

Context, not a figure

E-invoicing and statutory integration

Invoices and filings pass through statutory integrations, so issuing them from the system with a submission and response log becomes part of operations rather than later administrative work.

With a documented log

Anti-money-laundering obligations

Client identification, document retention and reporting are the licensed entity’s responsibility; we build the client register, the document record and the trace of the technical procedure, and we grant no compliance and issue no certificate.

A trace, not a certificate

A monthly close that cannot be deferred

The close, reconciliations and reports are statutory dates, so the system must hold up at the close peak without stalling, and separate the permission to enter from the permission to approve.

Entry separated from approval

We state the context because it explains the requirements — not to sell with it: we publish no market size, no growth rate, no programme target and no expected return or saving percentage, and we issue no regulatory compliance certificate. The licensed entity carries the statutory responsibility; we implement and document the controls.

Operations

Four operation types — and four different scopes

The same sector does not mean the same project. Read your operation first, then what fits you — and, plainly, what does not.

Accounting and bookkeeping practice

Several clients · monthly close · documents and reconciliations

What it suffers from
Each client sits in a separate file: documents are requested by email, reconciliation is deferred until work quietens, and the close slips so months pile up without visibility.
What fits it
Separated books per client with entries and attachments, a published document-request list, bank reconciliation completed on time, a monthly close with a clear output per client, and a status report the client reads.

What does not fit you: Running advisory services or analytical reporting before the close and reconciliation are disciplined, a complex billing system for a single client, and dashboards before periods are closed.

Instalment finance

Contracts and schedules · collection and follow-up · receivables ageing

What it suffers from
The schedule lives in a file, follow-up runs on calls, arrears surface late, and which contract has drifted from its schedule and by how much is unknown.
What fits it
A contract with a record and an instalment and receivable schedule, a recorded collection per payment, ageing read periodically, a client contact log, and reconciliation between collection and the books.

What does not fit you: Marketing or loyalty campaigns before collection and ageing are disciplined, multiple price lists before the schedule is stable, and complex payment integration before receivables are controlled.

Investment and portfolio management

Assets and contracts · income and maintenance cycles · owner reporting

What it suffers from
The asset, the contract and the income sit across files, so the owner report is assembled by hand and the actual return of a specific asset and its expenses are unknown.
What fits it
An asset record with its contract, expenses and actual income, a per-owner report built from its data, rent collection and maintenance cycle follow-up, and a published comparison of recorded against planned return.

What does not fit you: Presenting an expected return as if realised, managing investments in a file separate from accounting so the numbers disagree, and owner reports with no link to actual expenses.

Payment and wallet services

High transaction volume · daily settlement · a trace per operation

What it suffers from
Settlement runs on provider files, differences are handled by manual search, and no trace shows the state of each transaction against the counterparty.
What fits it
Recording every transaction with its status and reference, daily reconciliation against the provider file, an exception record for each difference and its cause, and fee and commission reporting on published rules — with no card data through our systems.

What does not fit you: Relying on the provider file as the only source with no internal record, handling differences by hand with no exception log, and connecting several wallets before the first settlement is stable.

The bands here are indicative guidance rather than an official classification, and the criterion is the nature of the obligation: a practice owes a client close, an instalment business owes a contract and a schedule, an investment manager owes an asset, a contract and a recorded return, and a payment service owes settlement and a trace per movement. More than one can coexist in a firm, and each has a different starting point.

Symptoms

What usually shows up in financial entities

Eight recurring symptoms, each with a different root cause — which is why the treatment differs even when the complaint sounds the same.

Non-unified master data

The account, client or cost centre appears in different forms per user, doubling the work and making a fast close impossible.

Cause: no unified chart

Deferred bank reconciliation

Reconciliation is deferred until work quietens, so differences accumulate and tracing their cause becomes impossible months later.

Cause: deferred reconciliation

An instalment schedule not followed

The schedule exists but is not compared with collection periodically, so default is discovered late and ageing swells.

Cause: no periodic follow-up

An entry edited with no trace

Who edited an entry or approved a payment and when is unknown — the first thing requested in any review.

Cause: no audit trail

Entry permission equals approval permission

The same user enters and approves, so separation of duties loses meaning and an error goes undetected.

Cause: no separation of duties

Settlement with no exception log

A difference is handled by manual search and closed without recording its cause, so the same difference repeats monthly.

Cause: a difference without a cause

An expected return presented as realised

Planning is mixed with outcome in the owner report, so a decision is taken on a figure that has not happened yet.

Cause: plan mixed with actual

A close that slips a month

Reports are built on an unclosed period, so figures change after publication and trust in them is lost.

Cause: an unclosed period

Components

What we implement in your operation

Eight components built in order according to your operation; we do not implement all of them for an entity that does not need them all.

Chart of accounts and master data

Unified accounts, clients and cost centres under one naming and published rules — the base every later report rests on.

The base

Entries, documents and attachments

An entry with its document and attachment and a document-request log, so nothing is searched for at review and nothing is entered unsupported.

An entry with its support

Bank reconciliations and the close cycle

Reconciliation completed on time, a close checklist with a published output, books-to-accounts reconciliation, and a difference report with its cause.

A close on time

Contracts, instalment schedules and receivables

A contract with its schedule and receivables, a recorded collection per payment, and ageing read periodically rather than awaited at period end.

Collection followed up

Asset, income and expense register

An asset with its contract, actual income and expenses, an owner report built from its data, and a clear separation of plan from actual.

Recorded, not promised

Settlement and the exception log

Recording every transaction with its status and reference, periodic reconciliation with the counterparty file, and an exception record for each difference and its cause.

A difference with its cause

Permissions and the audit trail

Separation of entry from approval, least-privilege permission per role, and an audit trail for every entry, payment and edit.

Separation of duties

Reporting and e-invoicing

Reports on a closed period decisions can be read from, and e-invoicing through the statutory integration with a submission and response log — with no promise about returns.

A decision, not an archive

Method

The method: from master data to the close

Eight stages, each with a published output, starting with unifying master data and reconciliation rather than with configuration — because a report on non-unified data is a misleading number.

  1. 01

    Assessment and operation type

    A visit covering the financial cycle, invoicing and collection, establishing the real operation type, what runs on spreadsheets today, and where the largest regulatory or financial risk sits.

    Output: an assessment naming your type
  2. 02

    Unifying master data

    A unified chart of accounts, clients, cost centres and naming, with duplicates cleaned — before any configuration, because a report on them is a misleading number.

    Output: unified master data
  3. 03

    Opening balances and reconciliation

    Migrating opening balances matching banks and accounts, and completing a first documented period reconciliation with its differences — the base that prevents error accumulation.

    Output: matching documented balances
  4. 04

    Permissions and separation of duties

    Defining who enters, who approves and who reviews, the audit trail, and an attachment policy — before opening the books to everyone.

    Output: separated duties and an audit trail
  5. 05

    Configuration and testing

    Configuring entries, invoices, contracts and settlement, and running a full cycle on anonymised data: entry, invoice, collection, reconciliation, close.

    Output: one complete tested cycle
  6. 06

    Phased go-live

    Going live on one client, branch or contract type first, then expanding — not switching all books in one day nor at the close peak.

    Output: one cycle running, then expansion
  7. 07

    Training and guides

    Training each role on its own process: the accountant at the entry, finance at the approval, the collector at the payment — with illustrated guides left with you.

    Output: a guide per role
  8. 08

    Integration, periodic close and improvement

    Connecting e-invoicing, banks and accounting, closing a first full period, and periodically reviewing differences and their causes and any report nobody uses so it can be dropped.

    Output: a documented close and periodic improvement

The durations shown are planning ranges to help you build your schedule, not contractual commitments: the actual duration depends on how clean your data is, how fast reconciliations proceed and how quickly permissions are approved, and can be affected by the close peak or reporting season.

Measurement

What we measure in a finance project

Indicators read from the operation itself, not promises about returns or profit.

Master-data completeness

The share of accounts, clients and cost centres registered per the unified chart, because every report after it rests on this classification.

Reconciliations completed on time

The share of bank reconciliations completed within their published time, because deferral is what makes differences unexplainable.

Audit-trail completeness

The share of entries and payments tied to a trace showing who entered, who approved and when, because that is what is requested in any review.

Instalment and receivable schedule accuracy

The gap between the instalment schedule and actual collection, because follow-up rests on a matching figure rather than an estimate.

Monthly close speed

The days from period end to its close, because a report on an unclosed period loses trust when its figures change.

We announce no return, no profit, no collection rate and no saving, and no figures about market size or programme targets. What we measure is master-data completeness, the share of reconciliations completed on time, audit-trail completeness, instalment and receivable schedule accuracy, and how fast the monthly close is — figures read from your system about your operation.

Integration

Where the system lives in your operation

We connect what you have instead of forcing its replacement, and we inspect every interface before promising it.

Odoo (accounting, stock and purchasing)

Entries, invoices and stock on the same books, so figures are not run in two systems or copied by hand.

The primary integration

Banks and statements

Importing statements for reconciliation, or connecting only if the bank provides an interface, and after inspecting it; we promise no bank integration without one.

After the interface check

E-invoicing and statutory reporting

Connecting invoicing to the statutory integration with a submission and response log, and exporting the data authorities require — while statutory responsibility stays with the licensed entity.

With a documented log

Payment and collection providers

We connect the transaction result (amount, status, reference) to the system; the card is read on the provider’s terminal and never passes through our systems or gets stored.

An explicit boundary

Authority and client systems

Connecting what can genuinely be connected among portals or client systems, after inspecting the interface; if none is available we say so and promise nothing.

After the interface check

Boundaries

Where our scope stops — written before you ask

In finance, systems get conflated with licensing, advice, compliance and payments, so the separation is written out plainly.

Licensing, compliance and regulatory reporting

We are not a licensed financial institution and represent no regulator: we hold no licence, handle no licensing procedure and issue no compliance certificate; statutory and regulatory responsibility rests with the licensed entity.

Financial, tax and legal advice

We give no investment, financial, tax or statutory accounting advice, prepare no filings on your behalf and express no opinion on an accounting treatment.

Shariah rulings and product permissibility

We issue no Shariah ruling or opinion on the permissibility of a product or financing structure; that belongs to your Shariah advisor, and we do not build on an assumption of our own.

Card data, payment devices and guarantees

We do not store, process or transmit payment card data, supply no payment devices and guarantee no profit, return or collection rate; payment happens on a licensed provider’s terminal and we connect only the result.

When what is needed falls outside our scope we say so in the assessment and refer a licensed party or a qualified adviser instead of accepting it and learning at your regulatory obligation’s expense. That is written in the contract, not left to courtesy.

FAQ

Questions specific to financial entities

Direct answers on licensing, advice, data and what we do not guarantee.

Are you a licensed financial institution or a payment service provider?

No. We are a systems company: not a bank, a finance company, a payment service provider or an investment firm, holding no licence from any regulator, representing none and handling no licensing procedures. What we do is build the system that runs and documents the operation, while licensing, regulatory compliance and the responsibility for regulatory reporting remain with the licensed entity — and we say so at assessment stage, before the contract rather than after it.

Do you guarantee profit, a return or a collection rate?

No. A return is set by the market, the asset, risk and timing, and collection is set by clients’ ability, your procedures and the market — neither is controlled by an administrative system. What we do commit to is that every contract, instalment schedule, collection movement, expense and actual return is recorded with its conditions, and that ageing and reconciliations are read from matching figures rather than estimates. Anyone guaranteeing a return or a collection rate in this sector guarantees what they do not own, and we do not offer it.

Do you provide financial advice or Shariah rulings?

No. We give no investment, financial, tax or statutory accounting advice, and we issue no Shariah ruling or opinion on the permissibility of a product or a financing structure — that belongs to your Shariah advisor, your statutory accountant and your auditor. Our role is to build the system that records what has been agreed and produces its documents; if the product itself is subject to a Shariah or regulatory opinion, the decision is not ours and we do not build on an assumption of our own.

What usually stops finance systems projects?

Three things we see repeatedly, none of them technical: non-unified master data — accounts, clients and cost centres shaped differently by each user, making a fast close impossible; deferred bank reconciliations, so differences accumulate until their cause can no longer be found; and broad permissions with no audit trail, so who edited an entry or approved a payment is unknown. That is why we start with master data, reconciliation, the audit trail and permissions, before any promise of a report or a dashboard.

Does a small financial firm need a full system?

No. It needs three things done well: unified master data, bank reconciliation completed on time, and a clear separation between who enters and who approves. Advanced dashboards, analytical reporting and bank connections add setup and entry a small team cannot carry and get abandoned after months so the figures return to spreadsheets. An abandoned project is worse than a small successful one — and we say so at assessment stage even when it means a smaller scope for us.

How do you handle anti-money-laundering requirements?

We build the tools, not the compliance: a documented client register, a document and attachment log with a defined retention period, a technical trace of every action (who opened a file and who reviewed it, and when), and reports that produce what a review requests. Determining requirements and what suffices for compliance and reporting is the licensed entity’s responsibility and its adviser’s; we issue no compliance certificate and express no regulatory opinion. That separation is written into the contract because it protects both sides.

What is out of scope?

Financial and banking licensing and its procedures, and regulatory reporting; investment, financial, tax and statutory accounting advice and the preparation of filings; Shariah rulings and product permissibility; payment card data, payment devices and their supply; guaranteed profit, returns or collection rates; field collection on your behalf; insurance and brokerage; running the treasury or portfolios on your behalf; system and cloud licences (contracted in your name); and publishing market-size figures or national programme targets. We say all of this at assessment stage, before the contract.

Which operation are you?

Tell us your operation type, the number of clients or contracts and the daily transaction volume, and whether reconciliations or collection are managed, and we will come back with an assessment naming your type, the fitting scope — and what does not fit you.

  • An assessment that names your operation type
  • A written scope before any commitment
  • A plain statement of what is outside our scope
Request a proposal

Related topics

We are a systems implementation and integration company, not a licensed financial institution, a bank, a finance company, a payment service provider or an investment firm: we hold no licence, represent no regulator and handle no licensing or regulatory reporting, give no investment, financial, tax or statutory accounting advice, and issue no Shariah ruling or opinion on a product’s permissibility. We guarantee no profit, no return, no collection rate and no saving; card data never passes through our systems and is never stored, and we supply no payment devices; and we publish no figures about market size or national programme targets. Statutory and regulatory responsibility rests with the licensed entity as the data controller, and durations shown are planning ranges rather than commitments.