SGE: from the class request to the invoice, in the same system

A custom system that carries a request through to invoicing, with role-based access, approvals on the record and documentation attached to it.

🔐 role-based access for each team
📋 from request to invoicing, in one system
☁️ AWS infrastructure under our management

The project

SGE is the system IBS Americas uses to run a nationwide training programme: classes opened across several regions, each with its own facilitator and its own materials. The class is the visible part — behind it sits an administrative chain with deadlines and with accounts to render. That chain is what the system had to support.

What the project called for

The class is the visible part. The system has to cover what comes before it and what comes after.

👥

Many people on the same record

Different teams touch the same record at different moments — each needing to see their part and not be able to touch the rest.

Deciding before executing

Some decisions have to happen before execution, and the path of that decision has to be recorded inside the system, recoverable later.

🧑‍🏫

The rule for who can be assigned

Availability and registration status have to hold at assignment time. A rule that is not in the system depends on somebody remembering it.

🔐

Budget alongside the request

Budget tracking has to travel with the request record: kept apart from it, it becomes a control nobody can check.

What we built

A system that follows the demand from request to billing.

🗂️

Role-based access

Each team signs in with its own access and sees the screens for its role, all tied to the same request record.

Approval flow with history

The request goes through an approval flow and every step stays in the history: you can reconstruct who decided what, and when.

🚦

Assignment with the rule in the system

Assigning a facilitator respects the availability rules held in the record: whoever is not eligible cannot be assigned. The rule lives in the system.

🧮

Amounts calculated at entry

The amounts for a request are calculated by the system as it comes in, from versioned rules — change the rule and what was already calculated stays intact.

📦

Kits, modules and materials

Kits assembled from modules and material lists per model: what a class receives is defined once and reused, instead of rebuilt for every edition.

📎

Documentation attached to the request

What proves it happened stays attached to the record itself, available to whoever has to render accounts later.

💰

Budget, invoicing and invoices

The request stays alive in the system through to invoicing: budget control, billing and invoice issuing in the same place.

📥

Bulk import

Requests, changes and registrations come in by import. A whole schedule does not have to be typed one by one.

📊

Dashboards and reports

The tracking dashboards and reports come out of what is already recorded, inside the system itself.

🔐

The participant area

Invitation, pre-registration and, at the end, the participation certificate: whoever takes the course also has their part in the system.

🛡️

Security as routine

The system holds sensitive data on many people, so oversight is permanent: updates applied, fixes for disclosed vulnerabilities shipped and periodic environment reviews.

What is live

The fronts the system supports today.

Role-based access Approval flow Approval history Assignment with status rule Facilitator records Kits and modules Material lists Attached documentation Budget control Billing and invoices Bulk import Dashboards and reports Participant area Security management

What it changes in practice

The effect of keeping the whole chain in one system.

1

The books match the operation

Because the demand goes from request to billing without changing systems, what was delivered and what was charged come from the same record.

2

Approval leaves a trail

When someone needs to know why a request was approved, the answer is in the history of the system itself.

3

The rule holds at the right moment

The status lock prevents assigning someone who is not available, and the amounts already come calculated from the moment the request is entered.

4

Budget alongside the request

Budget data travels with the request from the moment it is opened, so budget tracking happens inside the system.

What this project shows is a whole chain in a single system: from request to invoicing, without switching tools halfway.

Does your operation approve, deliver and bill in different systems?

When the whole chain lives in one place, accountability stops being a separate project. Tell us how your operation works today.