ARM End-to-End Billing Process¶

The 4×4 Framework¶

The ARM billing process is built on a clear conceptual model: 4 NetSuite records × 4 Feoda processes. This framework applies universally to every school, regardless of client-specific configuration. The underlying mechanics are identical — only the configuration varies.

The 4 NetSuite Records¶

#	Record	NetSuite Type	Description
1	Debtor	Customer Record	The family entity billed for tuition. Billing is always to the debtor (family), not to an individual parent or student. Each debtor has a unique ID and billing title.
2	Items	Service Item / Discount Item	Charges (tuition, fees, levies) and discounts (sibling, staff, scholarship) configured in NetSuite. Items are global records — not linked to a specific family until billing instructions are created.
3	Transaction	Invoice or Sales Order (Billing Order)	The financial document sent to families. Can be a standard invoice or a sales order (called a "billing order"), depending on the client's billing model.
4	Payment	Payment Record / Customer Deposit	Payment applied against the transaction. Created automatically through RPS processing (credit card or direct debit).

Key point: These are standard NetSuite records. Feoda does not replace NetSuite's accounting engine — it builds an automation layer on top of it.

The 4 Feoda Processes¶

┌──────────────────────┐    ┌──────────────────────┐    ┌──────────────────────┐    ┌──────────────────────┐
│  1. NETSUITE SETUP   │───▶│ 2. BILLING CONFIG    │───▶│ 3. TRANSACTION GEN   │───▶│ 4. PAYMENT PROCESS   │
│                      │    │                      │    │                      │    │                      │
│ • Create/import      │    │ • Link items to      │    │ • Review & verify    │    │ • Parent receives    │
│   debtors            │    │   students by rules  │    │   billing totals     │    │   payment link       │
│ • Create/import      │    │ • Configure billing  │    │ • Generate invoices  │    │ • Selects payment    │
│   students           │    │   period, terms,     │    │   or billing orders  │    │   method & schedule  │
│ • Set up items       │    │   payment options    │    │ • Send emails with   │    │ • RPS processes      │
│ • Set up discounts   │    │ • Generate billing   │    │   invoice PDFs       │    │   payments auto-     │
│                      │    │   instructions       │    │                      │    │   matically          │
└──────────────────────┘    └──────────────────────┘    └──────────────────────┘    └──────────────────────┘

Process 1: NetSuite Records Setup¶

1.1 Debtors (Customer Records)¶

Source: Imported from the school's Student Information System (SIS) or created manually.
Structure: Each debtor represents a family, not an individual parent. One debtor may have multiple students.
Fields:
Debtor ID: Unique identifier (numeric or alphanumeric, depending on school convention)
Debtor Name / Billing Title: The mailing/billing name for correspondence
Contact details: Email address(es) for invoice delivery and payment links
Students (sub-list): Students attached to the debtor record

1.2 Items¶

Service Items: Tuition fees, campus levies, laptop hire fees, extracurricular fees, enrollment deposits, online programs, building levy
Discount Items: Sibling discounts, staff discounts, scholarship discounts, boarding discounts
Items are configured globally and then mapped to students through the Billing Configurator and billing instructions.

1.3 Year Levels / Student Types¶

Define which items apply to which students based on:
Year level (e.g., laptop hire for years 7–10 only)
Student type (all students, staff children, boarding students, indigenous students, scholarship recipients)
Family order (for sibling discounts — 1st child, 2nd child, 3rd+ child)

Process 2: Billing Configurator¶

The Billing Configurator is Feoda's proprietary tool for automating the item-to-student mapping. It exists as a NetSuite Suitelet and is the layer that creates billing instruction and billing instruction applied-to records automatically based on user selections.

⚠️ Current State: The configurator is approximately 10% functional. The UI (suitelet) exists with all 9 tabs, but most back-end logic is incomplete. See Configurator Discussion Meeting Extraction for full architectural discussion and recommendations.

2.1 Configurator Suitelet — Tab Structure¶

The configurator suitelet is organized into 9 tabs. When fully functional, a school administrator would progress through these tabs to configure their billing cycle:

Tab	Name	Purpose
1	Segmentation	Select which charge categories and discount categories apply. Data sourced from the billing engine type field on item records.
2	Items	Select which items from the NetSuite item list should be included in this billing cycle. Not all items are billed every cycle (e.g., one-time fees, discontinued items).
3	Families/Debtors	Pull the full list of families and confirm which ones to include. Pre-selects all active debtors — school deselects any that need manual handling. Also serves as a reconciliation checkpoint (student count verification).
4	Items-to-Years Mapping	Map each selected item to the year levels and student types it applies to (e.g., laptop hire → year 8 and 11 only; staff discount → staff student type only). Student types are configurable per school.
5	Exceptions	Exclude specific students, families, or groups from particular items or rules that would otherwise apply to them.
6	Scheduling/Period	Set the billing period (start date, end date), configure preset messages for families with pending balances, and set exclusion rules for debtors with outstanding amounts.
7	Payments	Configure which payment options appear on the parent payment suitelet (credit card, bank/direct debit) and the available frequencies (weekly, fortnightly, monthly) with configurable split counts per frequency.
8	Mid-Year	Handle students who enroll mid-year — sets a different billing period and uses a divisible value to calculate prorated amounts. One-time setup, not run per mid-year enrollment.
9	Maintenance	Data cleansing utility — deletes stale custom records created by previous billing cycles. Can be scheduled to auto-clean every 3 or 6 months.

After completing the tabs, the configurator executes and creates: - Billing Instruction records — one per item per year level (e.g., "Student Year Fee 7"), storing the item, year level, billing period, and engine type - Billing Instruction Applied To records — child records listing every student/family that instruction applies to

2.2 Input Modes¶

Three modes exist for getting billing instructions into the system. The mode depends on the school's SIS data quality and integration maturity:

Mode	When Used	How It Works
Automated Configurator	SIS data quality supports automated processing	School uses the configurator suitelet (or subset of tabs). Billing instructions generated automatically on submit.
CSV Upload	SIS data quality requires manual reconciliation	Billing instructions prepared in CSV, uploaded into billing instruction records. Team reconciles student counts with the school before generating invoices.
Excel Import	Data comes from a data warehouse rather than a live SIS	Billing instructions built in Excel, imported into the Family Billing Profile custom record. Review suitelet provides filters for school verification before execution.

Goal: Evolve toward a single, robust billing configurator that handles all client variations through configuration rather than separate processes.

2.3 Three-Layer Architecture Vision¶

The strategic direction for the configurator is a three-layer architecture:

Layer	Description
Layer 1: Generic Base	Core billing engine features (~10-15 features) that apply to any school. Standard, never customized per client. Deployed as a bundle/app onto any NetSuite account.
Layer 2: Configurable	Point-and-click configuration for school-specific preferences — items, year mappings, payment options, billing frequency. This is what the configurator UI handles.
Layer 3: Custom/Exception	An open framework for school-specific exceptions that can't be handled by configuration. Must integrate back into the central solution. Each exception should be evaluated for promotion to the generic base.

See Configurator Discussion Meeting Extraction for the full architectural discussion behind this recommendation.

Process 3: Transaction Generation¶

3.1 Review & Verification¶

Before generating transactions, the school reviews: - Total number of students billed (must match expected count) - Total amount per item category - Discounts applied correctly - Any anomalies or duplicates

Review tools vary by client: - Automated configurator: Built-in summary screen showing totals - Review suitelet: Custom filtered view with drill-down to debtor-level detail (Pymble) - Manual review: Spreadsheet reconciliation with the school (Al Faisal)

If totals don't match, billing instructions are deleted and regenerated.

3.2 Generate Transactions¶

Transaction Type	Used By	Description
Invoice	Saint Edwards, Al Faisal	Standard NetSuite invoice. Straightforward — represents the amount owed.
Billing Order (Sales Order)	Pymble	A sales order used as a billing container. Invoices are generated from it incrementally (e.g., one per term). School clicks "Next Bill" to generate the next invoice. Offers more flexibility for term-based billing with split amounts.

3.3 Email Distribution¶

After invoice generation: - Invoices are emailed to families as PDF attachments - Email templates include: - Invoice summary - Payment suitelet link (unique URL per family) - Payment instructions - Follow-up reminder emails sent for outstanding invoices

Process 4: Payment Processing¶

4.1 Parent Payment Setup¶

Parents receive a unique URL (generated from debtor code + transaction ID) leading to a payment suitelet:

Authentication: OTP verification or SSO via JWT token (e.g., Pymble integrates SSO through the school's parent portal)
Payment information display: Billing title, family code, number of students, itemized charges and discounts, credit/debit balances
Payment method selection (varies by school):
Credit card (via eway)
Direct debit / bank (ABA file)
Edstart (third-party education fee payment provider)
B Pay (Australian payment reference system)
Schedule selection (varies by school):
Flexible date (parent chooses when — weekly, fortnightly, monthly)
Fixed term dates (e.g., four dates per year aligned to school terms)
Annual (full year payment, optionally split across dates)
Confirmation: Summary screen → confirm → RPS (Recurring Payment Schedule) created

4.2 "Paid from Portal" Protection¶

Once a parent submits their payment selection, a "Paid from Portal" checkbox is set on the billing record. This prevents: - Another parent in the same family from making a duplicate payment - The second parent sees a read-only summary instead of the payment selection screens

4.3 Automated RPS Processing¶

A daily scheduled script processes payments: - Picks up all RPS records where the processing date matches today - For credit card: submits to eway, receives authorization response - For direct debit: generates ABA file for bank upload - Creates payment records in NetSuite and applies them to the invoice

See: RPS Payment Processing for full details.

4.4 Monitoring¶

Schools monitor billing status through: - Saved searches: Outstanding payments, collection rates, overdue invoices - RPS status tracking: Processed, pending, cancelled, refunded - Payment history: Full audit trail per family

Client Implementation Comparison¶

Feature	Saint Edwards	Al Faisal	Pymble
Billing configurator	Automated (Step 1-2-3-4)	CSV upload	Excel import via Family Billing Profile
SIS integration	Direct	Manual (CSV due to data quality challenges with Central SIS)	Data warehouse → Excel
Transaction type	Invoice	Invoice	Billing Order (Sales Order)
Billing frequency	Yearly	Per term (4 terms)	Termly or Annual (parent choice)
Payment date flexibility	Flexible (parent chooses)	Fixed term dates	Fixed term dates or annual split
Payment methods	Credit card, Direct debit	Credit card, Direct debit	Bank, Credit card, Direct debit, Edstart, B Pay
Parent portal	Feoda suitelet	Feoda suitelet	My Pymble → redirects to Feoda suitelet
Building levy option	No	No	Yes (parent opts in/out)
Annual billing discount	No	No	Yes (2.5%)
Opening balance	Post-invoicing (bulk or individual)	N/A	Included in suitelet display
Email via	NetSuite email	NetSuite email	Portal notification + email

Lessons & Strategic Insights¶

Configurator-first approach: The billing configurator should be the standard path for all new clients. Investing in a robust, configurable version that handles variations (flexible vs fixed dates, term vs annual, building levy, extracurriculars, discount tiers) reduces per-client customization and accelerates onboarding.
SIS data quality is critical: The success of the automated configurator depends on reliable data from the school's Student Information System. Where SIS data is not yet reliable, the CSV/Excel path provides a workable interim solution while the integration is stabilized.
Scope clarity during onboarding: Defining and prioritizing billing requirements during the pre-sale and discovery phase ensures the implementation team can plan effectively. Schools typically need all billing features from day one, so a phased rollout of individual billing capabilities is not practical — the configurator needs to support the full scope at launch.
Proven scalability: Feoda's commercial implementation (BPOS — 8 companies, 6 countries, 4 business lines) demonstrates the platform can support complex, multi-entity billing at scale. The same underlying patterns apply to education billing.
Version control discipline: Each new school onboarding risks creating a divergent version of the billing solution. The three-layer architecture (generic base → configurable → custom) is essential to prevent version fragmentation. The development account must remain the permanent central source of truth, with code flowing: GitHub → dev account → demo + client accounts.
Standardization opportunity: There is an opportunity to consolidate the parent payment suitelet into a single configurable version that adapts to each school's requirements (payment methods, billing options, portal integration) through configuration rather than per-client builds.