> For the complete documentation index, see [llms.txt](https://docs.doku.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.doku.com/wallet-as-a-service/sub-account/dashboard-and-reports.md).
# Dashboard and Reports
## Dashboard
Create and manage sub-accounts, inspect balances and transactions, and receive daily reconciliation reports — without writing code
The Sub-Account dashboard is for the people on your team who should not have to call an API — operations, finance, and support. It shows the same data as the API, in real time.
| | URL |
| ---------- | ------------------------------------------------------------------------------ |
| Sandbox | [sandbox.doku.com/bo/sac/dashboard](https://sandbox.doku.com/bo/sac/dashboard) |
| Production | Your production DOKU Dashboard → **Wallet as a Service** → **Sub Account V2** |
***
### Who Can Access
The dashboard requires an **Admin** or **Finance** role on your DOKU account. Other roles cannot open it.
Your business name and current role are shown at the bottom of the side navigation.
***
### Activate the Service
Sub-Account must be activated on your business account before it appears in the dashboard or accepts API calls.
To see how Sub-Account works before activating anything, use the [Sub-Account demo](https://sandbox.doku.com/demo/sub-account).
1. Log in to your DOKU Dashboard, then open the side navigation
2. Navigate to **Settings** > **Service**
3. Click **+** Add Service
4. Under **DOKU Product**, expand **Wallet as a Service**
5. Select the service you need, then click Activate
#### Wallet as a Service options for Sub Account
| Option | What it enables |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Collect and Route / Deposit System / Fund Oversight** | **Sub-Account itself.** One checkbox, three capabilities: accept payments and split payment (Collect & Route), BRI VA Topup and drawn down per transaction (Deposit System), and DOKU e-Wallet linking for staff funds (Fund Oversight). Activating it adds the **Sub Account V2** menu and opens the Sub-Account V2 API. |
| **Unified Ledger** | Points on top of Sub-Account. Adds the `DOKU_MERCHANT_POINT` account and point top-up, purchase, refund and void. Tick it alongside the row above if you track points |
> **Point top-up failing on an otherwise working integration?** Check that **Unified Ledger** is active before debugging the request.
***
### Sub Account V2 — the Sub-Account List
**Wallet as a Service** > **Sub Account V2** opens **Overview**, which lists every sub-account under your merchant profile.
| Column | What it tells you |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The account holder name given at registration |
| **Profile ID** | SAC-xxxx-xxxxxxxxxxxxx `identifies the sub-account, not one of its balances. It is the value you put in` additionalInfo.account.id to route a payment to this party |
| **Type** | The sub-account type, e.g. `DEFAULT` |
| **Level** | Depth in the hierarchy, with a **View Chart** link to see the tree. Your merchant profile is **Level 1**; its direct sub-accounts are Level 2, theirs are Level 3, and so on |
| **Created Date** | Registration date and time |
| **Status** | `ACTIVE` or `INACTIVE` |
Every column sorts. **Search by name** and **Filter** narrow the list, **Reset Filter** clears them, and the page size selector plus **Showing x – y from z entries** handle long lists.
Your own merchant profile appears in this list as the Level 1 row, identified by your `BRN-` code rather than a `SAC-` Profile ID.
#### Row actions
The **⋮** menu on each row offers:
| Action | What it does |
| ---------------------- | --------------------------------------------------------------- |
| **See Details** | Opens the detail page — balances and transaction history |
| **Create Sub-Account** | Creates a child under this sub-account |
| **Edit** | Changes the sub-account's details |
| **Move** | Re-parents the sub-account, changing its place in the hierarchy |
| **Deactivate** | Sets the status to `INACTIVE` |
| **Delete** | Removes the sub-account |
> **Move, Deactivate and Delete have no API equivalent.** Register Sub Account creates accounts; restructuring the hierarchy and deactivating or deleting an account are dashboard-only. Plan hierarchy changes as an ops task, not an automated one.
***
### Create a Sub-Account
Useful for onboarding a few accounts by hand, or for support recreating a case. For onboarding at signup, use Register Sub Account instead.
1. On Sub Account V2 Page, click **+ Create Sub-Account**
2. Complete the form
3. Click **Create**
| Field | Required | Description |
| ---------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Yes | Account holder name, maximum 128 characters |
| **Parent Sub-Account** | No | Select or type an existing sub-account name to nest the new account beneath it. Leave empty to create it directly under your merchant profile |
| **Type** | Yes | The sub-account type |
| **Email** | No | Email address of the account holder |
| **Referral Code (Optional)** | No | Auto-generated. Click **Edit** to set your own |
These are the same fields as the Register Sub Account API — `name`, `parentProfileId`, `type`, `email` and `referralCode`.
***
### Sub-Account Details
Opened from **See Details** or by clicking a row. **View in Chart** shows where the account sits in the hierarchy.
The header carries **Profile ID** (with a copy button), **Type**, **Email**, **Referral Code**, and **Status**.
#### Balances
One card per account, each showing its **Account Number**, **Account Type**, and current balance:
| Card | Account Type | Notes |
| ---------- | --------------------------- | -------------------------------------------------------------------------------------------------- |
| **Points** | `DOKU MERCHANT POINT` | Only present when Unified Ledger is active. Adds no menu of its own — it appears as a balance card |
| **IDR** | `DOKU MERCHANT PENDING IDR` | Awaiting settlement — **not yet spendable** |
| **IDR** | `DOKU MERCHANT IDR` | Withdrawable balance |
Two things behind these numbers cause most "the balance looks wrong" questions:
* **Pending IDR is not spendable yet.** Funds from Checkout or Direct API land there and only move to Merchant IDR after settlement.
#### Transaction History
| Control | Purpose |
| ------------------------ | --------------------------------------------------------------------------------- |
| Account selector | **Choose which account's history to show** — Merchant IDR, Pending IDR, or Points |
| **Search by Invoice ID** | Find one transaction |
| Date range | The period to display |
| **Reset Filter** | Clear all three |
Columns: **Invoice ID**, **Description**, **Amount**, **Last Balance**, **Transaction Date**.
> **Two filters explain nearly every "my transaction is missing" report.** History is shown **per account**, so point transactions are invisible while the selector is set to an IDR account. And the date range defaults to a recent window — widen it to reach older transactions.
***
### Report, Dashboard, or API?
Three ways to reach the same data. The question is who is doing the work, and how often.
| | Report | Dashboard | API |
| ----------------------------------------- | ------------------- | ------------------------ | ---------------------- |
| Running balance per row | Yes | Yes | No — derive by summing |
| Scheduled and unattended | Yes | No | Yes, if you build it |
| Whole hierarchy in one file | Yes | Per account | Per account |
| Spreadsheet-ready | Yes — CSV or xlsx | No | Build it yourself |
| Real time | No — as at delivery | Yes | Yes |
| Restructure hierarchy, deactivate, delete | No | **Yes — dashboard only** | No |
| Use the dashboard when | Use the API when |
| --------------------------------------------------------------------------------- | ------------------------------------------------- |
| A person needs to look something up — a balance, a transaction, a failed callback | Your platform acts automatically, per transaction |
| Onboarding a handful of sub-accounts by hand | Onboarding sub-accounts as your users sign up |
| Support is answering "where is my money?" | Your own UI answers that for your users |
| Restructuring the hierarchy, deactivating or deleting an account | — |
Use reports for daily finance reconciliation, the dashboard when a person is investigating something, and the API when your own system needs the data.
Anything that must happen per transaction and in real time belongs in your integration — accepting payments, applying split rules, debits and refunds, payouts, point movements, and receiving notifications.
***
### Reconciliation Reports
DOKU can send daily reports of your sub-account activity, so your finance team can reconcile without querying the API or exporting by hand. Reports cover only your own sub-accounts.
| | |
| ------------- | --------------------------------- |
| **Frequency** | Daily |
| **Format** | **CSV** or **xlsx** — your choice |
Two templates are available, and most merchants who reconcile daily use both:
| Report | What it gives you |
| -------------------- | ---------------------------------------------------------------------------------- |
| **Balance History** | Every debit and credit against an account, with the running balance after each one |
| **Transaction List** | Every transaction with its type, status, channel, and the accounts on both sides |
To request either report — or to change its format, schedule, or recipients — [Contact Sales](https://www.doku.com/en-us/contact-sales).
#### Sample files
A filled sample of each template, so you can see the columns and test an import before the first delivery:
{% file src="/files/vbiehdyERhEDHbJCmJVH" %}
{% file src="/files/DNjnTgXJSHnwAD2Zrvw9" %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.doku.com/wallet-as-a-service/sub-account/dashboard-and-reports.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
