Al Faisal — Solution Design¶
ARM Configuration¶
Billing Configurator Mode¶
Al Faisal uses CSV upload for billing instructions. The automated billing configurator exists in the account but is not currently in use.
Background: An API integration was built with Central (Al Faisal's SIS) and ran for approximately one year, but data quality issues caused persistent mismatches between Central's data and NetSuite. Due to go-live timeline constraints, the team switched to CSV-based billing instructions as a reliable interim path. The automated configurator will be re-evaluated once the Central integration is stabilized.
Billing Instruction Process¶
- Team reconciles student counts per campus with the school against Central data
- Manual corrections are applied where campus assignments are incorrect
- Billing period (e.g., 2026) is updated via CSV import
- Billing instructions are generated via script after reconciliation is confirmed
- School reviews totals before invoice generation
Transaction Type¶
Invoice (standard NetSuite invoice). One invoice per family per billing term.
Billing Frequency¶
Per term — 4 terms per year. Fixed term billing dates (not flexible/parent-chosen).
Items¶
- Service Items: Tuition fees, extracurricular fees, online programs, enrollment deposits
- Discount Items: As applicable per student
Email Distribution¶
Invoices are emailed to families via NetSuite with: - PDF invoice attachment - Payment suitelet link (unique URL per family) - Payment instructions - Email templates updated per cycle
Payment Schedule¶
Fixed term dates — parents pay on four school-mandated dates per year (aligned to term starts).
Payment Methods¶
| Method | Provider | Notes |
|---|---|---|
| Credit card | eway | Fully automated via RPS daily script |
| Direct debit | ABA file | ABA file generated by script, uploaded to bank portal manually |
Authentication¶
OTP (One-Time Password) — parents receive a unique URL and verify via OTP to access the payment suitelet.
Customer Deposits¶
Customer deposits are used for enrollment purposes (year 7 and year 1 enrollments) and are created through the enrollment module — not through RPS. RPS always creates payment records, not customer deposits.
Debtor Naming Convention¶
- Debtor ID: Numeric or alphanumeric code per school convention
- Debtor Name: Mailing/billing title used for correspondence
RPS Processing¶
Daily scheduled script processes all RPS records with today's processing date: - Credit card: submitted to eway in real-time - Direct debit: included in ABA file generation
Process Mapping¶
| Client Process | Feoda Standard Process | Variation |
|---|---|---|
| 4-term billing | ARM Transaction Generation | Fixed term dates (not flexible) |
| CSV billing instructions | ARM Billing Configurator (manual/CSV mode) | Automated configurator not in use (pending SIS stabilization) |
| Manual campus reconciliation | Pre-billing data validation | Additional manual reconciliation step required before each cycle |
| Enrollment deposits | Customer Deposit (via enrollment module) | Separate from billing/RPS flow |
Design Decisions¶
| # | Decision | Rationale |
|---|---|---|
| D-001 | CSV upload instead of automated configurator | Central SIS data quality issues prevent reliable automated processing; CSV provides control and accuracy |
| D-002 | Fixed term dates | School mandates payment on term dates; no parent flexibility |
| D-003 | Customer deposits via enrollment module only | Prevents confusion between advance payments (deposits) and recurring invoice payments (RPS) |