DEV Community: NGB Platform

NGB Reports: Canonical + Composable Reporting on .NET and PostgreSQL

NGB Platform — Tue, 12 May 2026 13:19:53 +0000

I just published a new demo of NGB Reports — the reporting layer of NGB Platform.

NGB Platform is an open-source, metadata-driven business platform for building accounting-first industry solutions. The goal is not to build isolated CRUD applications, but complete business applications where documents, catalogs, accounting, operational registers, audit history, workflows, and reports are part of the same architecture.

This demo focuses specifically on reporting.

Why reporting matters in business applications

In many business systems, reporting is added late.

The application starts with forms, tables, documents, and workflows. Then, at some point, users need visibility:

What happened?
Which documents created accounting entries?
What is the current balance?
Which invoices are still open?
What is the profitability by project?
Can I drill down from a report number to the source document?

If reporting is treated as a separate dashboard layer, it often becomes disconnected from the real business model.

For NGB, reporting is a first-class platform capability.

Reports need to understand the same metadata, document model, accounting structures, and navigation patterns as the rest of the application.

What the demo shows

The video walks through reporting inside the Agency Billing vertical, but the reporting engine itself is platform-level and reusable across different NGB-based industry solutions.

The demo covers:

Canonical accounting reports
Composable business reports
Report Composer
Grouping
Filters
Fields
Sorting
Report variants
Drilldowns from reports to source documents
Document-aware reporting
The reporting architecture behind the platform

Canonical reports vs composable reports

NGB Reports supports two important reporting models.

Canonical reports

Canonical reports are predefined reports with strong business semantics.

Examples include accounting reports such as:

Trial Balance
Balance Sheet
Income Statement
Cash Flow Statement
General Journal
Account Card
General Ledger
Ledger Analysis

These reports are not just generic grids. They represent known accounting/reporting concepts and can have specialized execution logic, validation rules, paging strategies, and drilldown behavior.

Composable reports

Composable reports are more flexible.

They allow users to configure:

Row groupings
Column groupings
Visible fields
Filters
Sorting
Aggregations
Variants

This is useful for business-specific reports such as unbilled time, invoice registers, project profitability, aging reports, and operational summaries.

The goal is to provide flexibility without turning the system into an unstructured reporting sandbox.

Report Composer

One of the main parts of the demo is the Report Composer.

The Composer allows users to configure report layout and behavior directly from the UI:

General parameters
Grouping
Filters
Fields
Sorting
Variants

The important design goal is that the frontend is metadata-driven. The UI does not need to hardcode every report layout manually. The backend provides report definitions and presentation metadata, and the frontend renders the report experience consistently.

This keeps the platform extensible as new verticals and reports are added.

Drilldowns and document-aware reporting

For business users, numbers in reports should not be dead ends.

If a report shows a balance, invoice, account, project, or document-related value, the user should be able to navigate to the underlying source.

In the demo, reports can drill down into source documents and related business records. This is especially important for accounting-first applications because users often need to trace a number back to the document or posting that produced it.

This is one of the areas where reporting becomes tightly connected to the platform architecture.

Reports are not only about displaying data.

They are also about explainability.

Architecture direction

NGB Reports is designed around a few principles:

Metadata-driven definitions

Reports are described by definitions and presentation metadata, instead of being hardcoded page by page.
Reusable platform engine

The same reporting infrastructure can be reused across different verticals.
Canonical + composable model

Some reports need strong predefined semantics. Others need flexible user composition.
Document-aware navigation

Reports should connect back to documents, catalogs, accounts, and business entities.
Production-oriented execution

Reporting needs to handle paging, validation, stable execution paths, and performance considerations from the beginning.

Tech stack

NGB Platform is built with:

.NET
PostgreSQL
Vue
Metadata-driven architecture
Kubernetes-oriented deployment practices

The reporting engine is part of the broader NGB Platform architecture, which includes documents, catalogs, accounting, operational registers, reference registers, audit history, background jobs, and vertical-specific business modules.

Links

Video demo:

https://youtu.be/euqMDpjEcsM

GitHub:

https://github.com/ngbplatform/NGB

Website:

https://ngbplatform.com

Documentation:

https://docs.ngbplatform.com

Final thought

Reporting is not just a UI table.

In accounting-first business applications, reporting is part of the core product architecture.

It needs to be connected to documents, accounting entries, business entities, auditability, and navigation.

That is the direction behind NGB Reports.

How NGB Platform Works: Documents, Posting, Registers, and Reporting

NGB Platform — Tue, 05 May 2026 13:38:22 +0000

A follow-up: how the architecture works

In my previous article, I explained why I built NGB Platform and what problem it is trying to solve:

I Built an Open-Source Platform Foundation for Accounting-Centric Business Apps

That article was mostly about the why.

Why generic web frameworks are not enough for serious business applications.

Why large ERP products solve many of the right problems, but often inside closed and complex product ecosystems.

And why I wanted to build an open-source platform foundation for accounting-centric business applications.

This article is the follow-up.

Instead of focusing on why NGB exists, I want to walk through how the architecture works:

how documents represent business intent
how posting turns that intent into durable effects
how accounting entries and registers preserve business truth
how audit history and reporting are connected to the same model
how multiple vertical solutions reuse the same platform core

I also recorded a short architecture walkthrough video.

The short version

The core idea behind NGB is simple:

Business documents are intent. Posting creates durable effects. Reports read from durable business truth.

That separation is the foundation of the architecture.

A draft document means:

This is what the user wants to do.

A posted document means:

This business event is now part of durable system truth.

That distinction matters because serious business applications cannot rely on mutable CRUD state alone.

They need traceability.

They need auditability.

They need reporting.

They need a way to explain not only what the current value is, but also how the system got there.

The flow: from document to business truth

A typical NGB flow looks like this:

A user creates or updates a document draft.
The runtime validates the payload against metadata and business rules.
The user posts the document.
Posting creates durable effects.
Those effects are persisted in PostgreSQL.
Reports, document flows, audit history, and UI screens read from durable state.

That is the high-level path.

But each step exists for a reason.

Step 1: Document draft

In NGB, documents are first-class platform concepts.

A document is not just a row in a table.

It represents a business action with meaning.

For example, depending on the vertical, a document can represent:

a lease
a rent charge
a payment
a credit memo
a sales invoice
a purchase document
a timesheet
a work order
a project invoice

At the draft stage, the document represents business intent.

It may be incomplete.

It may need validation.

It may still be edited.

It has not yet produced durable accounting or operational consequences.

This gives the system a clear boundary between:

preparing a business action
committing that action as system truth

That boundary is one of the most important parts of the architecture.

Step 2: Metadata and validation

NGB is metadata-driven.

That means the platform does not treat every form, grid, and payload as a one-off implementation.

Document and catalog definitions describe the structure of business objects.

The runtime can use those definitions to understand:

available fields
required fields
payload shape
document parts
validation rules
UI metadata
reporting metadata
allowed actions

This does not remove the need for business logic.

It creates a consistent foundation around it.

Instead of every vertical rebuilding the same infrastructure from scratch, vertical modules can focus on the business-specific rules that actually matter.

Step 3: Posting

Posting is the moment where a document becomes durable business truth.

This is not just a status update.

Posting is where NGB records the consequences of the business event.

A posted document may create:

accounting entries
operational register movements
reference register updates
document relationships
audit log records
reporting state

That means posting is a boundary.

Before posting, the document is intent.

After posting, the document has effects.

This is what makes the model different from a typical CRUD application where data is often edited in place and business consequences are scattered across services, triggers, reports, and custom tables.

Step 4: Accounting effects

NGB is accounting-first.

That does not mean every document is an accounting document.

It means the platform is designed with accounting semantics in mind from the beginning.

For money-moving or accounting-relevant events, posting can produce accounting entries.

Those entries are durable effects of the posted document.

The goal is not to hide accounting behind UI screens.

The goal is to make accounting consequences explicit, traceable, and reportable.

A report should be able to answer questions like:

Which document created this accounting entry?
Which period does it belong to?
Which accounts were affected?
Which dimensions were used?
How does this line connect back to the business workflow?

That is why accounting is part of the architecture, not an afterthought.

Step 5: Append-only effects and reversals

For accounting-centric systems, silently rewriting history is dangerous.

NGB follows an append-only philosophy for durable effects.

The idea is:

Posted business effects should be preserved. Corrections should be explicit.

When something needs to be corrected, the system should not simply mutate historical truth in place.

Instead, it should use reversal or storno-style semantics where appropriate.

This makes the system easier to audit.

It also makes reports more trustworthy, because they are based on recorded effects rather than a constantly rewritten version of the past.

This approach is especially important for systems that need financial reporting, period close, audit history, and operational traceability.

Step 6: Operational registers

Not every business effect is a double-entry accounting entry.

Business systems also need operational state.

Examples include:

open receivables
settlement balances
inventory quantities
occupancy state
work order progress
project hours
budget usage
pending applications
document relationships

NGB models this through operational registers.

Operational registers capture business state derived from posted documents.

They are not a replacement for accounting.

They are a complementary layer for operational truth.

Accounting can explain the financial effect.

Operational registers can explain the business state that the application needs to run workflows and reports.

Step 7: Reference registers

Some business facts are effective over time.

For example:

prices
rates
policies
account mappings
configuration values
reference facts

A value that is true today may not have been true last month.

A report or posting rule may need to know what value was effective at a specific point in time.

Reference registers help model this kind of time-aware reference data.

This matters because serious business systems often need historical correctness, not just current values.

Step 8: Audit history

Audit history is not optional in business software.

Users need to understand what changed.

Administrators need to understand who did what.

Developers need to debug business behavior.

Auditors need to trace facts back to their source.

NGB treats audit history as part of the platform foundation.

The goal is to make important business actions explainable:

document creation
posting
reversal
catalog changes
period close
workflow actions
state changes

Auditability should not be something added later when the system becomes important.

It should be designed into the system from the beginning.

Step 9: Reporting

In many applications, reporting starts as a few SQL queries.

Then it becomes a collection of special cases.

Then it becomes difficult to maintain.

NGB treats reporting as a first-class platform subsystem.

The goal is to support both:

canonical reports for important accounting and business scenarios
composable reports for metadata-driven analysis

Reports should not be disconnected from the rest of the platform.

They should understand documents, catalogs, dimensions, filters, grouping, sorting, accounting effects, registers, and drilldowns.

A report should not just show numbers.

It should help users navigate back to the business facts behind those numbers.

That is why reporting belongs in the architecture.

Why this is different from typical CRUD

A typical CRUD system often starts with tables and screens:

Create table. Build form. Add list page. Add report later.

That can work for simple applications.

But serious business software needs more structure.

NGB starts from a different model:

Define business documents. Validate intent. Post durable effects. Preserve history. Report from business truth.

That difference changes the shape of the system.

The architecture is not centered only around tables.

It is centered around business events and their durable consequences.

One core, multiple verticals

NGB is not built around a single demo application.

The same platform concepts are reused across multiple vertical solutions.

Current demonstration verticals include:

Each vertical has its own domain model.

Each vertical has its own catalogs, documents, workflows, posting rules, and reports.

But they reuse the same core ideas:

documents
catalogs
posting
accounting effects
operational registers
reference registers
audit history
reporting
metadata-driven UI

That is the point of the platform.

The goal is not to hardcode one industry solution.

The goal is to provide a reusable foundation for building accounting-centric vertical business applications.

Why .NET and PostgreSQL

NGB is built with a pragmatic stack:

.NET
PostgreSQL
Vue
Docker
Kubernetes-oriented deployment practices

The important architectural choice is that PostgreSQL is treated as the system of record.

For this kind of software, the database is not just a persistence detail.

It is where durable business truth lives.

The .NET runtime orchestrates commands, validation, posting, reporting, and vertical behavior.

PostgreSQL provides transactions, constraints, data integrity, and durable storage.

Vue provides the web client layer.

The stack is intentionally practical.

For business systems, boring and reliable technology is often the right choice.

What the video covers

The architecture walkthrough focuses on the model behind NGB.

It covers:

why CRUD alone is not enough for serious business software
how documents represent business intent
how posting creates durable effects
how accounting entries and registers preserve business truth
why append-only effects and reversals matter
how operational and reference registers fit into the model
how audit history and reporting connect to posted business events
how Property Management, Trade, and Agency Billing reuse the same platform core

The video is not a UI demo.

It is an architecture walkthrough.

The goal is to explain the core model behind the platform.

What NGB is - and what it is not

NGB is an open-source platform foundation for accounting-centric business applications.

It is not just another generic web framework.

It is also not positioned as a finished replacement for every established ERP product.

Instead, I think of it as a reusable architecture and runtime foundation for teams that need to build serious business applications with:

documents
posting
accounting effects
operational state
audit history
reporting
vertical extensibility

That is the space NGB is exploring.

Links

GitHub: https://github.com/ngbplatform/NGB

Docs: https://docs.ngbplatform.com

Website: https://ngbplatform.com

Architecture Brief: https://docs.ngbplatform.com/architecture/architecture-brief

Ecosystem Brief: https://docs.ngbplatform.com/ecosystem/erp-accounting-software-teams

Previous article: https://dev.to/ngbplatform/i-built-an-open-source-platform-foundation-for-accounting-centric-business-apps-b7g

Feedback welcome

I would especially appreciate feedback from people who have worked on:

ERP systems
accounting software
vertical SaaS
internal business platforms
.NET architecture
PostgreSQL-backed business systems
reporting engines
audit-heavy applications

The area I am most interested in discussing is the architecture itself:

How should serious business applications model documents, posting, accounting effects, operational state, audit history, and reporting without rebuilding the same foundation every time?

That is the problem NGB is trying to solve.

I Built an Open-Source Platform Foundation for Accounting-Centric Business Apps

NGB Platform — Tue, 28 Apr 2026 13:09:01 +0000

The problem I kept running into

Every serious line-of-business project I worked on eventually forced me to solve the same hard problems from scratch.

Not the fun architectural problems.

The tedious, load-bearing ones that every business system needs but most general-purpose frameworks deliberately do not provide:

A document model with lifecycle, posting, and reversal
An accounting engine with real ledger semantics
Operational registers for stock, balances, and settlements
Reference registers for prices, rates, and effective facts
An audit log that explains what happened and why
Metadata-driven UI so forms are not hardcoded screen by screen
A clean way to build multiple vertical solutions on one shared core

The first time you build these things, you think:

OK, that was hard, but now I know how.

The second time, you think:

I should have kept that code from the last project.

The third time, you think:

There has to be a better way.

That is the problem I wanted to solve.

Two common options — and a missing third path

In practice, teams usually end up choosing between two imperfect options.

Option 1: Generic web frameworks

ASP.NET Core is excellent.

But it deliberately stays out of your business domain. It gives you HTTP, routing, middleware, dependency injection, authentication integration, and hosting primitives.

That is exactly what a general-purpose framework should do.

But it also means every serious business application team eventually has to design its own document lifecycle, posting model, audit trail, reporting approach, and business state tracking.

Option 2: Large ERP products

SAP, Oracle, Dynamics, and similar systems have solved many of these problems.

But they solve them inside a product.

Customization can be difficult. Vendor lock-in is real. The cost and complexity can be high. And for many teams, the problem is not “we need to install an ERP.”

The problem is:

We need to build a business application, but we do not want to rebuild the same accounting and workflow foundation again.

The missing option: a reusable platform foundation

This is what I set out to build.

Not another generic web framework.

Not a full ERP replacement.

But a reusable open-source foundation for accounting-centric business applications.

What I built — NGB Platform

NGB Platform is an open-source platform foundation for accounting-centric business applications, built on .NET 10 and PostgreSQL.

The goal is to handle the hard, load-bearing concerns at the architecture level, so teams can focus on their vertical domain instead of rebuilding infrastructure on every project.

Core architecture

At the center is NGB.Runtime — the orchestration layer for document workflow, posting, reporting, validation, and response shaping.

Specialized engines handle specific concerns:

NGB.Accounting — ledger semantics, posting flows, debit/credit effects, and financial reporting
NGB.OperationalRegisters — movement-based state tracking such as stock levels, settlement balances, and operational balances
NGB.ReferenceRegisters — effective fact tracking such as prices, rates, terms, and other point-in-time facts
Business AuditLog — append-only history of what happened, who did it, and what effects were produced

Everything persists through NGB.PostgreSql into PostgreSQL, which acts as the authoritative system of record.

Authentication is handled by Keycloak.

Background jobs are handled by Hangfire.

The frontend is built with Vue 3 + Vite + Tailwind CSS, using a shared metadata-driven UI workspace.

The whole platform can run locally with Docker Compose.

Key design decisions

Append-only effects instead of silent mutation

Every business action produces explicit, durable effects.

Reversals are new records, not deletions.

That means the system can explain what happened, when it happened, who triggered it, and how it affected accounting, operational registers, reference registers, and audit history.

The goal is not just to store data.

The goal is to preserve business meaning.

Metadata-driven documents and UI

Documents, catalogs, forms, lists, actions, and UI behavior are described as metadata.

The frontend does not need a custom hardcoded form for every business document.

This makes it possible to build new vertical solutions on the same runtime without rewriting the whole application layer each time.

Hosts compose, libraries execute

API hosts, background job hosts, and watchdog hosts are thin composition roots.

Business logic lives in runtime services, engines, providers, and vertical modules — not scattered across controllers or HTTP handlers.

That separation has been one of the most important architectural decisions in the project.

Three live vertical demos

To prove that the same platform core can support different business domains, I built three vertical solutions.

Property Management

Leases, tenants, rent charges, receivables, payments, credit memos, allocations, maintenance requests, work orders, and accounting reports.

Trade

Products, inventory, purchase orders, sales orders, invoices, stock movements, supplier accounts, customer accounts, and trade-focused reporting.

Agency Billing

Clients, contracts, service delivery, billing runs, revenue recognition, and agency financial reporting.

All three share the same runtime, accounting engine, reporting pipeline, PostgreSQL provider, and Vue UI framework.

Demo login works for all three demo environments:

Email: alex.carter@demo.ngbplatform.com
Password: DemoAdmin!2026

Demo environments:

Tech stack

Backend: .NET 10, C#
Database: PostgreSQL
Authentication: Keycloak
Background jobs: Hangfire
Migrations: Evolve
Frontend: Vue 3, Vite, Tailwind CSS
Local development: Docker Compose
License: Apache 2.0

Getting started

git clone https://github.com/ngbplatform/NGB.git
cd NGB
docker compose -f docker-compose.ab.yml \
  --env-file .env.ab up --build

Full documentation:

https://docs.ngbplatform.com

GitHub repository:

https://github.com/ngbplatform/NGB

What I would love feedback on

If you have built serious line-of-business software on .NET, I would genuinely love your feedback.

In particular:

Does this architecture make sense to you?
What would you do differently?
Which part would you want to see explained in more detail?
Is there a vertical use case you would like to see covered?

NGB Platform is open source under the Apache 2.0 license.

Version v1.0.0 has just been released.

Stars are welcome, but architecture feedback is even more valuable.