Skip to content

Standalone ARM — Product Requirements

Vision

Build a standalone, ERP-agnostic Accounts Receivable Management (ARM) product that replaces the current NetSuite-embedded ARM module. The new ARM must be:

  • Standalone — operates independently of any specific ERP system
  • Generic — serves any education institution (schools, nurseries, universities) and potentially other recurring-billing industries
  • ERP-Agnostic — integrates with Oracle NetSuite, Microsoft Dynamics 365, and any future ERP via a standardized integration layer
  • Comprehensive — covers all existing client requirements (e.g. Saint Edwards, Al Faisal, Pymble) plus predicted future needs
  • Configurable — adapts to client-specific billing models through configuration, not custom code

Why Standalone?

The current ARM module is tightly coupled to Oracle NetSuite (SuiteScript Suitelets, custom records, scheduled scripts). This creates:

  1. Version fragmentation — 4 schools, 3+ divergent codebases (documented in the 2026-02-19 configurator discussion)
  2. Platform lock-in — cannot serve clients using Microsoft Dynamics or other ERPs
  3. Limited functionality — billing configurator is ~10% functional
  4. Scalability constraints — NetSuite governance limits, SuiteScript execution caps
  5. Maintenance burden — changes must be deployed per-client via GitHub → dev account → demo + client accounts

Strategic Foundation

Based on three-layer architecture recommendation (2026-02-19):

Layer Description
Layer 1: Generic Base Core billing engine — ~15 features universal to any institution. Never customized per client.
Layer 2: Configurable Client-specific preferences handled through configuration UI — items, year mappings, payment options, billing frequency.
Layer 3: Custom/Exception Open framework for institution-specific exceptions. Each exception evaluated for promotion to the generic base.

Document Structure

This folder contains the full requirements specification for the standalone ARM product:

Document Description
Business Requirements Functional requirements organized by business domain — billing configuration, transaction generation, payment processing, debtor management, reporting
System Requirements Technical architecture, platform requirements, performance, scalability, API design
Data Model Entity definitions, relationships, field specifications — the universal data model for ARM
Integration Specification ERP connector architecture, SIS integration, payment gateway integration, portal/SSO integration
Configurator Specification Deep-dive into the billing configurator — the core UI for mapping items to students and generating billing instructions
Process Flows End-to-end process flows for billing, payment, and operational scenarios
Gap Analysis Current state vs target state analysis identifying gaps and effort required
Technology Stack Comparison Evaluation of technology options with recommendations
Cost Projections Infrastructure cost estimates across growth phases
Migration Plan Strategy for migrating existing clients from NetSuite to standalone
Implementation Kickoff Step-by-step setup guide for Azure DevOps, dev environment, and CI/CD

Scope

In Scope

  • Fee billing and invoicing for education institutions
  • Recurring payment collection (credit card, direct debit, bank transfer)
  • Billing configuration (mapping fees/discounts to students by rules)
  • Parent-facing payment portal
  • ERP integration (NetSuite first, Microsoft Dynamics second)
  • SIS/SMS integration for student data
  • Multi-campus, multi-currency support
  • Reporting and analytics

Out of Scope

  • General Ledger / accounting (handled by the connected ERP)
  • Student information management (handled by the connected SIS)
  • HR / payroll / procurement (handled by ERP)
  • Budgeting and forecasting (handled by EPM)

Current Client Baseline

Requirements are derived from three existing client implementations:

Client Key Features Configurator Mode Transaction Type Payment Dates
Saint Edwards Yearly billing, ~920 students, automated configurator Automated wizard Invoice Flexible (parent chooses)
Al Faisal Multi-campus, 4-term billing, CSV-based CSV upload Invoice Fixed term dates
Pymble Billing orders, portal SSO, 5 payment methods, building levy, 2.5% discount Excel import Billing Order (Sales Order) Fixed term or Annual

Stakeholders

Role Responsibility
Head of Technology Product owner, requirements definition, architecture decisions
Tech Team Development team responsible for designing, building, and delivering the standalone ARM platform
Solution Architect Domain expertise, current implementation knowledge, client relationship
Implementation Team Client onboarding, configuration, support
School Administrators End users of the configurator and billing management
Parents/Guardians End users of the payment portal