Standalone ARM — Business Requirements Specification¶
1. Document Purpose¶
This document defines the functional business requirements for the standalone ARM (Accounts Receivable Management) product. Requirements are organized by business domain and derived from:
- Three existing client implementations (Saint Edwards, Al Faisal, Pymble)
- The 4×4 Framework (2026-02-17 process session)
- Configurator architectural discussion (2026-02-19)
- BPOS commercial implementation precedent (8 companies, 6 countries, 4 business lines)
- Predicted future needs for education and recurring-billing institutions
Each requirement has a unique ID, priority, and source traceability.
Priority Levels¶
| Priority | Definition |
|---|---|
| P1 — Must Have | Core functionality required for MVP launch. Without this, the product cannot operate. |
| P2 — Should Have | Important functionality needed for production readiness. Can be delivered in early iterations post-MVP. |
| P3 — Nice to Have | Enhances user experience or covers edge cases. Scheduled for future releases. |
| P4 — Future | Predicted future needs. No current client requires this, but architecture should accommodate it. |
2. Debtor & Student Management¶
2.1 Debtor (Family/Account) Management¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-DEB-001 | The system shall support a Debtor entity representing a family/account — billing is always to the debtor, never to individual parents or students | P1 | All clients |
| BRS-DEB-002 | Each debtor shall have a unique identifier (Debtor ID) — supports both numeric and alphanumeric formats configurable per institution | P1 | Al Faisal, Saint Edwards |
| BRS-DEB-003 | Each debtor shall have a configurable billing title / display name used for correspondence | P1 | All clients |
| BRS-DEB-004 | The system shall support multiple contact email addresses per debtor (for invoice delivery, payment notifications) | P1 | All clients |
| BRS-DEB-005 | A debtor may have multiple students (children) attached to the same account | P1 | All clients |
| BRS-DEB-006 | The system shall support debtor status tracking (Active, Inactive, On Hold, Archived) | P1 | Predicted |
| BRS-DEB-007 | The system shall support importing debtors from external systems (SIS, ERP, CSV) via the integration layer | P1 | All clients |
| BRS-DEB-008 | The system shall support manual debtor creation through the admin UI | P2 | All clients |
| BRS-DEB-009 | The system shall support debtor merge/deduplication when duplicate records are detected | P2 | Saint Edwards (duplicates caught in billing cycle) |
| BRS-DEB-010 | The system shall support multi-parent/guardian association per debtor (e.g., mother, father, legal guardian) with individual contact details | P2 | Predicted |
| BRS-DEB-011 | The system shall track the financial relationship between parents and debtor (e.g., primary payer, secondary payer) | P3 | Predicted |
| BRS-DEB-012 | The system shall support custom fields on the debtor record configurable per institution | P2 | Predicted |
| BRS-DEB-013 | The system shall maintain a full audit trail of all changes to debtor records | P1 | Predicted |
2.2 Student Management¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-STU-001 | The system shall support a Student entity linked to a Debtor (family) | P1 | All clients |
| BRS-STU-002 | Each student shall have attributes: Student ID, Name, Year Level, Campus, Enrollment Status, Student Type | P1 | All clients |
| BRS-STU-003 | Student Types shall be configurable per institution (e.g., "All Students", "Staff Children", "Boarding", "Indigenous", "Scholarship") | P1 | Saint Edwards, Pymble |
| BRS-STU-004 | The system shall support a Family Order field per student within a debtor (1st child, 2nd child, 3rd+ child) for sibling discount calculations | P1 | Saint Edwards |
| BRS-STU-005 | The system shall support multiple students per debtor with different year levels, campuses, and student types | P1 | All clients |
| BRS-STU-006 | The system shall support importing student data from SIS/SMS systems via the integration layer | P1 | All clients |
| BRS-STU-007 | The system shall support manual student creation and editing through the admin UI | P2 | All clients |
| BRS-STU-008 | The system shall support student enrollment date tracking for mid-year billing proration | P1 | Configurator Tab 8 |
| BRS-STU-009 | The system shall support student withdrawal/departure date tracking with prorated billing implications | P1 | Predicted |
| BRS-STU-010 | The system shall track student status (Enrolled, Withdrawn, Graduating, Deferred) | P1 | Predicted |
| BRS-STU-011 | The system shall support campus assignment per student for multi-campus institutions | P1 | Al Faisal |
| BRS-STU-012 | The system shall maintain a full audit trail of all changes to student records | P1 | Predicted |
3. Item & Fee Management¶
3.1 Item (Fee & Discount) Management¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-ITM-001 | The system shall support a global Item catalog with two primary categories: Charges (fees) and Discounts | P1 | All clients, Configurator Tab 1 |
| BRS-ITM-002 | Charge items include: tuition fees, campus levies, laptop hire fees, extracurricular fees, enrollment deposits, online programs, building levy, amenity fees | P1 | All clients |
| BRS-ITM-003 | Discount items include: sibling discounts (by family order), staff discounts, scholarship discounts, boarding discounts, early payment discounts, indigenous provisions | P1 | All clients |
| BRS-ITM-004 | Each item shall have: Item ID, Name, Description, Category (charge/discount), Amount, Tax Treatment, Status, Billing Engine Type | P1 | All clients |
| BRS-ITM-005 | The system shall support a Billing Engine Type classification on items — a custom categorization used for segmentation (e.g., "Tuition", "Levy", "Discount - Sibling") | P1 | Configurator Tab 1, Glossary |
| BRS-ITM-006 | Item amounts shall be configurable per year level, campus, or student type (e.g., tuition varies by year level) | P1 | All clients |
| BRS-ITM-007 | Items shall be generic/global — not linked to a specific family until billing instructions are created | P1 | All clients |
| BRS-ITM-008 | The system shall support one-time items (e.g., enrollment deposit) and recurring items (e.g., annual tuition) | P1 | All clients |
| BRS-ITM-009 | The system shall support item versioning — maintaining historical pricing while supporting new rates per billing cycle | P2 | Predicted |
| BRS-ITM-010 | The system shall support tax-inclusive and tax-exclusive pricing per item | P2 | Predicted |
| BRS-ITM-011 | The system shall support item grouping/bundling (e.g., "Standard Package" = tuition + levy + technology fee) | P3 | Predicted |
| BRS-ITM-012 | The system shall support percentage-based discounts (e.g., 2.5% annual discount) and fixed-amount discounts | P1 | Pymble (2.5% discount) |
| BRS-ITM-013 | The system shall support conditional discounts based on payment behavior (e.g., paying annually vs. termly) | P1 | Pymble (annual discount) |
| BRS-ITM-014 | The system shall support optional/elective items that parents can opt into or out of (e.g., building levy contribution) | P1 | Pymble (building levy opt-in/out) |
| BRS-ITM-015 | The system shall support importing items from external systems (ERP, CSV) via the integration layer | P1 | All clients |
| BRS-ITM-016 | Items shall be importable and exportable in bulk (CSV/Excel) | P2 | All clients |
| BRS-ITM-017 | The system shall support multi-currency item pricing | P3 | Predicted (international schools) |
4. Billing Configuration¶
Full configurator UI/workflow requirements are in Configurator Specification. This section covers the business-level billing configuration rules.
4.1 Billing Instruction Generation¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-BIL-001 | The system shall generate Billing Instructions — records that define what each family is billed for (items, amounts, discounts, billing period) | P1 | All clients |
| BRS-BIL-002 | Billing instructions shall be generated through one of three modes: (a) Automated configurator, (b) CSV upload, (c) Excel/file import | P1 | All clients |
| BRS-BIL-003 | In automated mode, the configurator shall map items to students based on configurable rules: year level, student type, family order, campus, enrollment status | P1 | Configurator design |
| BRS-BIL-004 | The system shall support a Billing Profile per debtor — a container record holding all billing instructions for a family | P1 | Pymble (billing profile = subscription plan) |
| BRS-BIL-005 | The system shall support Billing Instruction as a master record per item per year level (e.g., "Tuition Year 7"), containing item, year level, billing period, and engine type | P1 | All clients |
| BRS-BIL-006 | The system shall support Billing Instruction Applied To as a child record mapping a billing instruction to specific students/families | P1 | All clients |
| BRS-BIL-007 | The system shall support exceptions — excluding specific students, families, or groups from particular items or rules | P1 | Configurator Tab 5 |
| BRS-BIL-008 | The system shall support mid-year pro-ration — calculating partial billing for students who enroll mid-year using a configurable divisible value | P1 | Configurator Tab 8 |
| BRS-BIL-009 | The system shall support configurable billing periods (start date, end date) — yearly, termly, semesterly, monthly, or custom | P1 | All clients |
| BRS-BIL-010 | The system shall support multiple billing cycles per year (1 for yearly, 4 for termly, 2 for semesterly, 12 for monthly) | P1 | All clients |
| BRS-BIL-011 | The system shall support configurable payment terms (e.g., 20 days, 30 days, custom) | P1 | Saint Edwards (changed from 24/30 to 20) |
| BRS-BIL-012 | The system shall support opening balance handling — applying outstanding amounts from prior periods to current billing | P1 | Saint Edwards, Pymble |
| BRS-BIL-013 | The system shall support bulk and individual opening balance application | P2 | Saint Edwards |
| BRS-BIL-014 | The system shall allow deletion and regeneration of billing instructions when totals don't match expected values | P1 | Saint Edwards (regenerated twice in 2026 cycle) |
| BRS-BIL-015 | The system shall support credit balance tracking and display (amounts owed to the family) | P1 | Pymble |
| BRS-BIL-016 | The system shall support maintenance/cleanup of stale billing records from prior cycles — manual or scheduled | P2 | Configurator Tab 9 |
| BRS-BIL-017 | The system shall support billing instruction templates — pre-configured sets of rules that can be reused across billing cycles | P3 | Predicted |
| BRS-BIL-018 | The system shall support rollover of billing configurations from one cycle to the next with minimal manual intervention | P3 | Predicted |
4.2 Reconciliation & Verification¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-REC-001 | The system shall provide a reconciliation checkpoint showing total student count, total families, and total billing amounts before transaction generation | P1 | All clients |
| BRS-REC-002 | The system shall allow comparison of expected vs. actual student counts per year level, campus, and student type | P1 | Saint Edwards (~920 students), Al Faisal (campus reconciliation) |
| BRS-REC-003 | The system shall detect duplicate debtors and duplicate students during the reconciliation process | P1 | Saint Edwards (3 duplicates caught in 2026 cycle) |
| BRS-REC-004 | The system shall provide a review screen with configurable filters (billing status, student type, item type, campus) for school verification | P1 | Pymble (review suitelet) |
| BRS-REC-005 | The system shall allow drill-down from summary totals to individual debtor-level billing detail | P1 | Pymble |
| BRS-REC-006 | The system shall block transaction generation until the school has explicitly approved the billing totals | P2 | Predicted |
| BRS-REC-007 | The system shall log reconciliation results (timestamp, user, counts, approval status) for audit purposes | P2 | Predicted |
5. Transaction Generation¶
5.1 Invoice & Billing Order Generation¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-TXN-001 | The system shall generate transactions from approved billing instructions | P1 | All clients |
| BRS-TXN-002 | The system shall support two transaction types: (a) Standard Invoice, (b) Billing Order (a container for incremental invoice generation) | P1 | Saint Edwards/Al Faisal (invoice), Pymble (billing order) |
| BRS-TXN-003 | Standard invoices shall represent the amount owed for a specific billing period — one invoice per family per period | P1 | Saint Edwards, Al Faisal |
| BRS-TXN-004 | Billing orders shall act as annual containers from which term invoices are generated incrementally (e.g., "Next Bill" action generates next term's invoice) | P1 | Pymble |
| BRS-TXN-005 | The system shall support configurable transaction templates (layout, branding, terms & conditions, payment instructions) per institution | P2 | Predicted |
| BRS-TXN-006 | Each transaction shall contain: Transaction ID, Debtor, Line Items (charges + discounts), Total, Due Date, Payment Status, Payment Link | P1 | All clients |
| BRS-TXN-007 | The system shall generate PDF invoices for email distribution | P1 | All clients |
| BRS-TXN-008 | The system shall support bulk invoice generation (all families in a billing cycle at once) | P1 | All clients |
| BRS-TXN-009 | The system shall support individual invoice regeneration for specific families | P2 | Predicted |
| BRS-TXN-010 | The system shall support credit notes for adjustments, refunds, or corrections to previously generated invoices | P2 | Predicted |
| BRS-TXN-011 | The system shall track transaction status (Draft, Pending, Sent, Partially Paid, Paid, Overdue, Cancelled, Voided) | P1 | All clients |
| BRS-TXN-012 | The system shall support a "Closed" / "Open" state on billing orders with the ability to reopen accidentally closed orders | P1 | Pymble (KI-002) |
| BRS-TXN-013 | The system shall support changing units/quantities on billing order line items to adjust term/annual amounts | P2 | Pymble |
| BRS-TXN-014 | The system shall sync generated transactions to the connected ERP system via the integration layer | P1 | All clients |
| BRS-TXN-015 | The system shall support multi-currency transactions | P3 | Predicted (international schools) |
5.2 Email & Communication¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-COM-001 | The system shall email invoices to families as PDF attachments upon generation | P1 | All clients |
| BRS-COM-002 | The system shall include a unique payment link (URL) in each invoice email | P1 | All clients |
| BRS-COM-003 | The system shall support configurable email templates per institution (branding, content, language) | P1 | All clients |
| BRS-COM-004 | The system shall support automated reminder emails for outstanding/overdue invoices with configurable intervals | P1 | All clients |
| BRS-COM-005 | The system shall support preset messages for families with pending balances (configurable per billing cycle) | P2 | Configurator Tab 6 |
| BRS-COM-006 | The system shall track email delivery status (sent, delivered, bounced, opened) | P3 | Predicted |
| BRS-COM-007 | The system shall support SMS/WhatsApp notifications as additional communication channels | P4 | Predicted (Phase 4 roadmap) |
| BRS-COM-008 | The system shall support multi-language email templates | P4 | Predicted (international schools) |
6. Payment Processing¶
Payment processing details including RPS, gateways, and direct debit are covered in this section and in the Integration Specification. This section covers business-level payment requirements.
6.1 Payment Methods¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-PAY-001 | The system shall support Credit Card payments via payment gateway integration (currently eway) | P1 | All clients |
| BRS-PAY-002 | The system shall support Direct Debit / Bank Transfer payments via bank file generation (currently ABA format) | P1 | All clients |
| BRS-PAY-003 | The system shall support B Pay (Australian bill payment reference system) | P2 | Pymble |
| BRS-PAY-004 | The system shall support Third-Party Payment Providers (e.g., Edstart — education fee payment provider) | P2 | Pymble |
| BRS-PAY-005 | The system shall support pluggable payment gateway adapters — architecture must allow adding new payment gateways without core code changes | P1 | Architecture requirement |
| BRS-PAY-006 | The system shall support pluggable bank file format adapters (ABA for Australia, SEPA for Europe, ACH for US, etc.) | P2 | Predicted (international expansion) |
| BRS-PAY-007 | The system shall support manual/offline payment recording (cash, cheque, wire transfer) | P2 | Predicted |
| BRS-PAY-008 | The system shall support partial payments against an invoice | P2 | Predicted |
| BRS-PAY-009 | The system shall support overpayments with automatic credit balance creation | P2 | Predicted |
6.2 Recurring Payment Schedule (RPS)¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-RPS-001 | The system shall create Recurring Payment Schedule (RPS) records when parents set up their payment method and schedule | P1 | All clients |
| BRS-RPS-002 | Each RPS record shall contain: Debtor, Transaction, Payment Method, Amount, Processing Date, Frequency, Status, Encrypted Payment Details | P1 | All clients |
| BRS-RPS-003 | The system shall support configurable payment frequencies: weekly, fortnightly, monthly, termly, annually | P1 | All clients |
| BRS-RPS-004 | The number of payment splits per frequency shall be configurable (e.g., monthly but only 10 months instead of 12, weekly but only 20 weeks instead of 24) | P1 | Saint Edwards, Configurator Tab 7 |
| BRS-RPS-005 | The system shall support flexible payment dates where parents choose their own payment dates | P1 | Saint Edwards |
| BRS-RPS-006 | The system shall support fixed payment dates mandated by the institution (e.g., term start dates) | P1 | Al Faisal, Pymble |
| BRS-RPS-007 | The system shall support annual payment with optional splitting across multiple dates (to accommodate bank transaction limits) | P1 | Pymble |
| BRS-RPS-008 | The RPS amount may differ from the invoice amount — it can include opening balances, building levy, and other adjustments | P1 | Pymble |
| BRS-RPS-009 | The system shall process RPS records automatically on a configurable schedule (default: daily) | P1 | All clients |
| BRS-RPS-010 | For credit card: the system shall submit payments to the payment gateway and create payment records on success | P1 | All clients |
| BRS-RPS-011 | For direct debit: the system shall generate bank files containing all payments due for the processing date | P1 | All clients |
| BRS-RPS-012 | The system shall track RPS status through a lifecycle: Created → Pending → Processing → Processed/Failed → Cancelled/Refunded | P1 | All clients |
| BRS-RPS-013 | The system shall store authorization codes and decline reasons on RPS records for audit and troubleshooting | P1 | All clients |
| BRS-RPS-014 | The system shall support automatic retry of failed payments with configurable retry policies (retry count, interval, backoff strategy) | P2 | Predicted |
| BRS-RPS-015 | The system shall support RPS cancellation with automatic cleanup of future scheduled payments | P1 | Predicted |
| BRS-RPS-016 | The system shall support refund processing — reversing a processed payment and creating a credit | P2 | Predicted |
6.3 "Paid from Portal" Protection¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-PFP-001 | The system shall set a "Paid from Portal" flag when a parent submits payment setup, preventing duplicate payment submissions from other family members | P1 | All clients |
| BRS-PFP-002 | When the flag is set, a second parent from the same family shall see a read-only summary of the payment setup — not the payment selection screens | P1 | All clients |
| BRS-PFP-003 | The system shall allow authorized administrators to reset the "Paid from Portal" flag (e.g., for payment method changes) | P1 | All clients |
6.4 Payment Method Changes¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-PMC-001 | The system shall support payment method changes before transaction generation — by resetting the billing order, clearing summary data, and allowing parent re-submission | P1 | All clients |
| BRS-PMC-002 | The system shall support payment method changes after transaction generation — by updating the recurrence record, all pending RPS records, and the invoice record simultaneously | P1 | All clients |
| BRS-PMC-003 | The system shall ensure all payment-related records are consistent after a payment method change (recurrence + RPS + transaction must all match) | P1 | All clients |
| BRS-PMC-004 | The system shall log all payment method changes with timestamp, user, old method, and new method for audit purposes | P1 | Predicted |
7. Parent Payment Portal¶
7.1 Portal Experience¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-PRT-001 | The system shall provide a secure, parent-facing payment portal accessible via unique URL per family | P1 | All clients |
| BRS-PRT-002 | The portal shall display: billing title, family code, number of students, itemized charges and discounts | P1 | All clients |
| BRS-PRT-003 | The portal shall display credit/debit balance for the family | P1 | Pymble |
| BRS-PRT-004 | The portal shall allow parents to select their payment method from the configured options | P1 | All clients |
| BRS-PRT-005 | The portal shall allow parents to select their payment schedule (frequency, dates) based on the institution's configuration | P1 | All clients |
| BRS-PRT-006 | The portal shall present a summary/confirmation screen before final payment submission | P1 | All clients |
| BRS-PRT-007 | The portal shall support optional/elective items (e.g., building levy) where parents can opt in or out | P1 | Pymble |
| BRS-PRT-008 | The portal shall support term vs. annual billing selection where the institution offers both options | P1 | Pymble |
| BRS-PRT-009 | The portal shall support date/amount splitting for annual payments (accommodate bank transaction limits) | P1 | Pymble |
| BRS-PRT-010 | The portal shall be responsive (mobile, tablet, desktop) | P2 | Predicted |
| BRS-PRT-011 | The portal shall be white-labeled / brandable per institution (logo, colors, terms) | P2 | Predicted |
| BRS-PRT-012 | The portal shall display payment history and invoice status for returning parents | P2 | Pymble (KI-001 — currently in progress) |
| BRS-PRT-013 | The portal shall support multi-language display | P4 | Predicted (international schools) |
7.2 Authentication¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-AUTH-001 | The system shall support OTP (One-Time Password) authentication for portal access | P1 | Saint Edwards, Al Faisal |
| BRS-AUTH-002 | The system shall support SSO via JWT authentication — integration with institution's parent portal (e.g., My Pymble) | P1 | Pymble |
| BRS-AUTH-003 | The system shall generate unique, secure URLs per family based on debtor code + transaction ID | P1 | All clients |
| BRS-AUTH-004 | The system shall support pluggable authentication adapters (OTP, JWT/SSO, SAML, OAuth 2.0) | P2 | Predicted |
| BRS-AUTH-005 | The system shall support session management with configurable timeout | P1 | Predicted |
8. Reporting & Analytics¶
8.1 Operational Reports¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-RPT-001 | The system shall provide an Outstanding Payments report — families with overdue/unpaid invoices with aging analysis | P1 | All clients |
| BRS-RPT-002 | The system shall provide a Collection Rate report — percentage of payments collected vs. total billed per period | P1 | All clients |
| BRS-RPT-003 | The system shall provide a Failed/Declined Payments report — RPS records with failure reasons for follow-up | P1 | All clients |
| BRS-RPT-004 | The system shall provide a Payment History report — full audit trail per family including all transactions and payments | P1 | All clients |
| BRS-RPT-005 | The system shall provide an RPS Status report — breakdown by date, method, and status | P1 | All clients |
| BRS-RPT-006 | The system shall provide a Billing Summary report — total billed per item category, year level, campus | P1 | All clients |
| BRS-RPT-007 | The system shall support configurable saved searches/filters on all reports | P2 | All clients |
| BRS-RPT-008 | The system shall support report export (CSV, Excel, PDF) | P2 | Predicted |
8.2 Management/Executive Reports¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-RPT-009 | The system shall provide a Revenue Dashboard — real-time view of total revenue, pending payments, and collection trends | P2 | Predicted |
| BRS-RPT-010 | The system shall provide a Comparative Analysis report — year-over-year billing and collection comparisons | P3 | Predicted |
| BRS-RPT-011 | The system shall provide a Forecast report — projected revenue based on current billing + RPS schedules | P3 | Predicted |
| BRS-RPT-012 | The system shall support scheduled/automated report delivery via email | P3 | Predicted |
9. Multi-Entity Support¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-MUL-001 | The system shall support multi-campus institutions — separate billing configurations per campus within the same institution | P1 | Al Faisal |
| BRS-MUL-002 | The system shall support institution-level and campus-level administrative views | P2 | Predicted |
| BRS-MUL-003 | The system shall support multi-company/subsidiary structures (e.g., a school group with multiple schools under one parent organization) | P3 | BPOS precedent (8 companies) |
| BRS-MUL-004 | The system shall support multi-country deployments with country-specific tax and payment rules | P3 | BPOS precedent (6 countries), Predicted |
| BRS-MUL-005 | The system shall support multi-currency billing with configurable exchange rates | P3 | Predicted |
| BRS-MUL-006 | The system shall support multiple business lines / divisions within a single organization | P4 | BPOS precedent (4 business lines) |
10. Notifications & Workflows¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-WKF-001 | The system shall support automated notification workflows triggered by billing lifecycle events (invoice generated, payment due, payment failed, payment received) | P2 | Predicted |
| BRS-WKF-002 | The system shall support escalation workflows for overdue payments (configurable escalation stages: reminder → warning → suspension notice) | P2 | Predicted |
| BRS-WKF-003 | The system shall support approval workflows for billing instruction changes, credit notes, and refunds | P2 | Predicted |
| BRS-WKF-004 | The system shall support configurable webhook/event notifications for integration with external systems | P2 | Predicted |
| BRS-WKF-005 | The system shall support scheduled exclusion of debtors with outstanding amounts from new billing cycles, with configurable thresholds and preset messages | P1 | Configurator Tab 6 |
11. Administration & Configuration¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-ADM-001 | The system shall provide an admin dashboard for institution administrators to manage billing cycles, monitor payments, and configure settings | P1 | Predicted |
| BRS-ADM-002 | The system shall support role-based access control (admin, billing manager, viewer, support agent) | P1 | Predicted |
| BRS-ADM-003 | The system shall support configurable institution settings: name, branding, timezone, currency, fiscal year, billing calendar | P1 | Predicted |
| BRS-ADM-004 | All configuration changes shall be logged with user, timestamp, old value, and new value | P1 | Predicted |
| BRS-ADM-005 | The system shall support feature flags for enabling/disabling features per institution (e.g., building levy, annual discount, B Pay) | P2 | Predicted |
| BRS-ADM-006 | The system shall provide a self-service configuration interface for items, debtors, billing periods, and payment options | P2 | Configurator vision |
| BRS-ADM-007 | Schools shall not be expected to fully self-serve — Feoda will run billing cycles for most clients, but the UI must support eventual self-service | P2 | recommendation discussed in meeting (2026-02-19) |
12. Enrollment & Deposits¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-ENR-001 | The system shall support Customer Deposits for enrollment purposes — separate from RPS billing payments | P2 | Al Faisal |
| BRS-ENR-002 | Customer deposits shall be advance payments collected through an enrollment module/workflow, not through the standard billing flow | P2 | Al Faisal |
| BRS-ENR-003 | The system shall support applying enrollment deposits against future invoices when the student's first billing cycle begins | P2 | Predicted |
| BRS-ENR-004 | The system shall support enrollment-specific items (e.g., enrollment deposit, registration fee) that are one-time charges separate from recurring billing | P2 | Al Faisal |
13. Data Retention & Archival¶
| ID | Requirement | Priority | Source |
|---|---|---|---|
| BRS-RET-001 | The system shall support configurable data retention policies per entity type | P2 | Predicted |
| BRS-RET-002 | The system shall archive completed billing cycles while maintaining query access to historical data | P3 | Predicted |
| BRS-RET-003 | The system shall support data export for regulatory compliance and migration purposes | P2 | Predicted |
| BRS-RET-004 | The system shall maintain a complete audit trail of all billing, payment, and configuration changes for a minimum of 7 years (configurable) | P1 | Predicted |
Appendix A: Requirement Traceability Matrix¶
| Source | Requirements Derived |
|---|---|
| Saint Edwards implementation | BRS-DEB-001–009, BRS-STU-001–004, BRS-ITM-001–003, BRS-BIL-001–014, BRS-TXN-001–003, BRS-PAY-001–002, BRS-RPS-001–005 |
| Al Faisal implementation | BRS-DEB-002, BRS-STU-011, BRS-BIL-002, BRS-MUL-001, BRS-ENR-001–004, BRS-RPS-006 |
| Pymble implementation | BRS-ITM-012–014, BRS-TXN-002–004, BRS-PAY-003–004, BRS-RPS-007–008, BRS-PFP-001–003, BRS-PRT-001–009, BRS-AUTH-002 |
| Configurator discussion (2026-02-19) | BRS-BIL-001–018, BRS-ITM-005, BRS-REC-001–007, BRS-WKF-005, BRS-ADM-007 |
| Process updates meeting (2026-02-17) | 4×4 Framework foundation — all core requirements |
| BPOS precedent | BRS-MUL-003–006 |
| Predicted / architecture | All P3/P4 requirements, security, multi-currency, multi-language |
Appendix B: Open Questions¶
| # | Question | Impact Area | Status |
|---|---|---|---|
| OQ-001 | What are the 10-15 "generic features" for Layer 1? Needs requirements workshop with Ravi and Ash | Architecture | Open |
| OQ-002 | Should the system support subscription-based pricing (monthly SaaS fee) or is it license-based? | Business model | Open |
| OQ-003 | What is the migration path for existing clients (Saint Edwards, Al Faisal, Pymble) to the standalone system? | Migration | Open |
| OQ-004 | What are the specific Microsoft Dynamics 365 integration requirements? | Integration | Open |
| OQ-005 | What regulatory requirements apply in the UAE vs. Australia vs. other target markets? | Compliance | Open |
| OQ-006 | Should the system support student-level billing (in addition to family-level) for certain institution types? | Data model | Open |
| OQ-007 | What are the exact BPOS billing features that should be carried over to the standalone ARM? | Feature parity | Open |
| OQ-008 | [PLACEHOLDER] Define exact discount calculation rules for edge cases (e.g., sibling discount when one student withdraws mid-year) |
Business rules | Open |
| OQ-009 | [PLACEHOLDER] Define exact pro-ration formulas for mid-year enrollment (daily? weekly? monthly?) |
Business rules | Open |
| OQ-010 | [PLACEHOLDER] Define late payment penalty rules — does any client charge late fees? |
Business rules | Open |