GoDravixA product byDigiWagon
Migration
Pricing
Book a demoSee the platform

Reporting & Dashboards

A portfolio dashboard filtered by financial year, scheme and zone; five standard reports; and the running ledger behind every figure. All of it exports.

Live moduleReporting & Dashboards
Reporting and dashboardsA portfolio dashboard with summary tiles, a scheme-wise bar chart and a zone split, filtered by financial year and scheme.FY 2026-27All schemesAll zonesLoans195Entities100+Zones3Scheme-wise outstandingZone split3zonesFive reports · every one exports to Excel and PDF
Running right now
Every number traces back to its eventsExcel and PDF export on all five reports and the ledger

Reporting in GoDravix is built around a simple test: can the person who receives a number trace it back to the events that produced it? The portfolio dashboard summarises, the five reports slice, and the running ledger shows every event with the balance after it.

Borrowers log in to a portal of their own, scoped to their own loans and nothing else.

What is built today

  • Portfolio dashboard

    Summary cards and charts across the whole book, for users with portfolio-wide access.

  • Financial year, scheme and zone filters

    Slice the dashboard by the dimensions institutional lenders actually report on.

  • Borrower portal

    Each borrower logs in to its own loans, balances, running ledger and a totals-only dashboard, scoped so nothing wider is reachable. Read-only.

  • Outstanding report

    Current position across the portfolio.

  • Repayment report

    Repayments recorded over a period, with allocation detail.

  • Scheme-wise report

    Portfolio grouped by lending scheme.

  • Entity-wise report

    Portfolio grouped by borrowing organisation.

  • Overdue report

    Accounts behind on repayment.

  • Complete running ledger

    Every event on a loan in sequence with the balance after each.

  • Excel and PDF export

    Every report and the ledger export in both formats.

Data scoping

Enforced where
the data is fetched.

Each borrower logs in to its own loans, balances and running ledger. A regional permission sees one zone in full. Neither can reach anything wider, because the constraint sits in the query rather than in the interface.

See reporting and dashboards
Portfolio, all borrowers
Borrowing body 02₹4,10,000
Borrowing body 03₹2,86,400
Borrowing body 05₹9,12,700
Signed in as borrowing body 04
Outstanding₹1,69,555
Active loans3
LN-2026-000418Active₹1,69,555
LN-2024-000211Closed₹0.00
Scoping constrains the data that is fetched, not the menu that is drawn. There is no URL that reaches another borrower.
Read-only. Borrowers see their position rather than transacting on it.

Five reports, and what each one is actually for

These are not five variations on a list of loans. Each maps to a question an institutional lender is regularly asked to answer, usually by somebody with the authority to insist.

ReportThe question it answersTypical audience
OutstandingWhat is owed to us right now, split across principal, interest and penal?Finance controller, board
RepaymentWhat came in over this period, and how was each payment allocated?Accounts team, auditor
Scheme-wiseHow is each lending scheme performing against the others?Programme owner, board
Entity-wiseWhat is our exposure to each borrowing organisation?Credit and risk, regional oversight
OverdueWho is behind, and by how much?Recovery team, management

Data scoping is enforced, not hidden

A permission scoped to one zone sees every borrower in that zone and nothing beyond it. A borrower sees its own loans and a totals-only dashboard. This is applied when the data is fetched, rather than by removing a menu item and hoping nobody constructs a URL.

It matters most in multi-tier structures, which is exactly where institutional lending lives. A state finance board lending through zones to municipalities needs each tier to see its own layer, and needs to be able to tell an auditor how that separation is enforced.

  • Zone-level scoping

    Regional oversight roles see one zone in full.

  • Entity-level scoping

    A borrowing organisation sees only itself.

  • Applied at query

    Scoping constrains the data fetched, not just the interface.

  • Auditor sees everything

    Read-only, portfolio-wide, by design.

Export, because the report is rarely the destination

Every report and the running ledger export to Excel and PDF. This is a mundane feature and one of the most used, because in most of the organisations we work with the report is an input to a board paper, a statutory return or an audit file rather than a final artefact.

Where reporting stops, and what happens instead: the five reports are fixed, so a sixth is a scoped development request rather than something you assemble yourself. Data leaves as Excel or PDF (an export rather than an API) so a warehouse or BI connection is something we would build against your requirement. Natural-language querying is one of the seven AI capabilities, built against your own book.

Scope

Where this module stops

These sit outside what this module does today. They are named here so a fit decision can be made now rather than during implementation.

  • Report builderThe five reports are fixed. A sixth is a scoped development change rather than a self-service designer.
  • Scheduled deliveryReports are pulled on demand rather than pushed on a schedule.
  • API and BI connectivityData leaves as Excel or PDF today. A REST API, webhooks and a BI connector are roadmap, so a warehouse feed would be built rather than configured.
  • Natural-language queryingAsk-Your-Portfolio would let you question the book in plain language. It sits third in the AI sequence.
None of this is automatically a no.

Some of it is built into an engagement, some is genuinely out of scope, and some is development we can quote against your requirement. Which one it is depends on your workflow, and that is a fifteen-minute conversation rather than a guess.

Talk it through with the team
Questions

About this module

Five standard reports: Outstanding, Repayment, Scheme-wise, Entity-wise and Overdue. Each exports to Excel and PDF, and each is filterable by financial year, scheme and zone where relevant. Alongside them sits the complete running ledger for any individual loan, showing every event in sequence with the balance after it.

Not yet. A report outside the five is a scoped development request with a timeline and a cost rather than something you assemble in the interface. Data reaches your own tools as Excel or PDF today; a REST API and a BI connector are roadmap, so a warehouse feed would be built for you.

Worth raising early if your reporting changes often, it is exactly the kind of thing a services team can quote against.

Each borrower gets its own login to the borrower portal: its loans, balances, running ledger and a totals-only dashboard, scoped so that no other borrower’s data is reachable. The portal is read-only by design. Borrowers see their position rather than transacting on it, so online payment, request submission and document upload from the borrower side are roadmap.

Not today. Reports are generated on demand and exported to Excel or PDF, which is how the monthly board pack is produced and circulated now. Scheduling and automated distribution are on the roadmap.

Keep reading

Related modules

Next step

See this module running on live data

We demo on the production deployment, not a sandbox with tidy numbers chosen to make the software look good.

45 minutes | On the live deployment | A straight answer on fit