Meeting Extraction — Feoda Process & Updates Session¶
Meeting Details¶
| Field | Value |
|---|---|
| Date | 2026-02-17 |
| Duration | 1h 26m 34s |
| Participants | Ravi Ramanujam, Pearl Blanco, Ash Alexander, Jayselle Sale, Sarah Shalfoun, Veda |
| Facilitator | Ravi Ramanujam |
| Recording | video.mp4 |
| Transcript | transcript.txt |
Context¶
The purpose of this session was to align the team on the end-to-end ARM billing process. Ravi observed that team members understood isolated parts of the process but lacked a unified view of the full flow. The session covered:
- Ravi's 4×4 Framework — a conceptual model for understanding the entire ARM billing process
- Live walkthroughs of three client implementations: Saint Edwards, Al Faisal, and Pymble
- RPS (Recurring Payment Schedule) processing — credit card and direct debit flows
- Lessons and strategic insights for future client onboarding
Key Topics Discussed¶
Topic 1: The 4×4 Framework (Ravi's Conceptual Model)¶
Summary: Ravi introduced a mental model for understanding the ARM billing process: 4 NetSuite records × 4 Feoda processes. This is the same regardless of the client — the fundamentals never change.
The 4 NetSuite Records:
| # | Record | Description |
|---|---|---|
| 1 | Debtor | The family/customer record in NetSuite. Billing is always to the debtor (family), never to a parent directly. The debtor is the customer record in NetSuite. |
| 2 | Items | Standard NetSuite items — charges (tuition, fees, levies) and discounts (sibling, staff, scholarship). Items are independent records, not linked to a specific family. |
| 3 | Transaction | Either an Invoice or a Sales Order (called "Billing Order" in some implementations). This is the financial document sent to families. |
| 4 | Payment | Payment records applied against invoices. Generated via RPS processing (credit card or direct debit). |
The 4 Feoda Processes:
| # | Process | Description |
|---|---|---|
| 1 | NetSuite Records Setup | Create/import debtors, students, items, discounts. These are standard NetSuite records — universal across any industry. |
| 2 | Billing Configurator | Feoda's proprietary tool that links items to students based on rules (year level, family order, boarding status, staff discount, etc.) and generates Billing Instructions. |
| 3 | Transaction Generation | Generate invoices or billing orders from billing instructions. Includes review and summary screens for the school to verify before execution. |
| 4 | Payment Processing | Parents receive a link (suitelet), set up their payment method/schedule, and RPS processes payments automatically via credit card (eway) or direct debit (ABA file). |
Key Insight: The Feoda bundle is not a standalone product — it is an automation layer on top of standard NetSuite records. The same 4 records and 4 processes apply universally to every school, regardless of complexity. The differences between clients come down to payment configuration and billing frequency.
Decisions Made: - The 4×4 Framework should be the standard way the team conceptualizes and explains the ARM billing process.
Topic 2: Saint Edwards Walkthrough (Ash)¶
Summary: Ash demonstrated the Saint Edwards implementation, which uses the full billing configurator.
Key Points: - Saint Edwards uses the complete billing configurator with a step-by-step process (Step 1-2-3-4), which the school follows and references in support communications. - Step 1: Select items applicable to the school — tuition fees, levies, laptop hire fees (year 7-10 only), staff discounts, etc. - Step 2: Verify families/debtors — confirm correct number of families and check for duplicates. - Step 3: Verify students — confirm correct number of students, check for duplicates (e.g., 3 duplicates caught this cycle). - Step 4: Configure item-to-student mapping — which item applies to which year level, student type (all students, staff children, boarding, etc.). - Billing period selection: Choose the applicable billing period (full year for Saint Edwards). - Payment terms: Configurable (changed from 24/30 to 20 this cycle). - Review & Summary: School reviews totals — must match expected student count (920 students). Billing instructions had to be deleted and regenerated twice this cycle to match numbers. - Execute: Generates invoices against all families. - Opening balance: After invoice generation, school calculates and applies opening balances (can be done in bulk or individually per record). - Email distribution: School sends invoices to all families via email, with follow-up reminder emails for unpaid invoices. - Payment: Parents receive flexible date selection — they choose when to pay. Saint Edwards offers weekly, fortnightly, or monthly payment options. RPS is created per parent's selection. - Monitoring: Saved searches show outstanding payments, collection status, and payment history. - Annual billing: Saint Edwards does yearly billing — one cycle per year, then monitoring until all payments are collected.
Topic 3: Al Faisal Walkthrough (Pearl)¶
Summary: Pearl demonstrated the Al Faisal implementation, which follows the same conceptual process but without the automated billing configurator.
Key Points: - The billing configurator exists in Al Faisal's account but is not currently used — billing instructions are uploaded via CSV instead. - Reason: Al Faisal's Student Information System (Central) had persistent data quality issues. The integration (built by MJ) ran for a year but Central's APIs consistently posted incorrect data, causing mismatches between the SIS and NetSuite. Due to time constraints for go-live, the team switched to CSV upload for billing instructions. - Items: Same structure as Saint Edwards — service items (tuition, extracurricular, online programs, enrollment deposits) and discount items. - Manual reconciliation: Before billing, the team reconciles student counts per campus with the school against Central data. Manual corrections are sometimes needed for campus assignments. - Period updates: The billing period (e.g., 2026) is updated via CSV import. - Billing instructions: Generated via script after reconciliation is confirmed with the school. - Invoice generation: Invoices include suitelet payment link (same OTP-protected link as other clients). - Email templates: Updated per cycle with PDF invoice attachments and payment instructions. - RPS: Created when parents click the payment link and set up their payment — four fixed term dates (not flexible like Saint Edwards). - Payment processing: Daily script picks up RPS by processing date and creates payment records. - Customer deposits: Created only through the enrollment module (year 7 and year 1 enrollments). These are advance payments, separate from RPS invoice payments. The RPS always creates payment records, not customer deposits. - Debtor naming convention: Debtor ID is a number or alphanumeric code; debtor name is the mailing/billing title.
Topic 4: Pymble Walkthrough (Ash)¶
Summary: Ash demonstrated the Pymble implementation, which is the most feature-rich, using billing orders instead of invoices and offering multiple payment options through a parent portal.
Key Points: - Pymble does not use the automated billing configurator — billing instructions are generated manually in Excel using data from Pymble's data warehouse, then imported into the Family Billing Profile custom record. - Billing order (sales order) is used instead of an invoice — a key difference from other implementations. - Review suitelet: A custom review screen with filters (billing status, student type, item type) for the school to verify totals before execution. Filters include indigenous students, scholarship, tuition fees, etc. - Debtor view: Drill-down to actual total invoice value per debtor. - Execute: Generates billing orders against families. - Parent portal integration: Pymble uses their own portal ("My Pymble"). Feoda sends the debtor code and transaction ID to the portal. When parents click "Pay Now" on the portal, they are redirected to Feoda's payment suitelet. - Payment suitelet features: - Billing title, family code, number of students, all applicable fees - Credit/debit balance display - Building levy option: Parents choose whether to contribute or not - Payment method selection: Bank, credit card, direct debit, Edstart, or B Pay - Term vs Annual: Parents choose term billing or annual. Annual allows splitting across multiple dates (for bank limit reasons — e.g., $20K on Jan 20, $20K on Jan 21). - Summary screen: Full summary of all choices before confirmation - Paid-from-portal checkbox: Once a parent has submitted, this checkbox prevents duplicate payments (if another parent from the same family logs in, they see only the summary, not the payment selection screens). - RPS amount vs invoice amount: RPS amount may differ from invoice amount because it includes opening balance and building levy in addition to tuition. - Authentication: Built by Sarah — SSO via JWT token. Debtor code + order ID (sales order internal ID) generates a unique URL per family, linked to the portal's pay button. Parents authenticate through My Pymble's SSO, which passes a JWT token to the Feoda suitelet. - Billing order management: - School can generate manual invoices by clicking "Next Bill" on the billing order (standard NetSuite process). - For term vs annual: changing units on the invoice adjusts amounts automatically. - Accidentally closed billing orders can be reopened by exposing the "closed" checkbox on the record.
Lessons & Strategic Insights: - Pymble's implementation accommodated a wide range of requirements (five billing options, building levy contributions, annual splitting, portal integration, credit balance display, 2.5% annual discount), creating a comprehensive solution. - Future approach: The team agreed that investing in a more robust, configurable billing configurator is the priority. A well-designed configurator with built-in support for the variations seen across Saint Edwards, Al Faisal, and Pymble would reduce per-client customization effort and allow faster onboarding. - Scope management insight: For future clients, requirements should be clearly defined and prioritized during the pre-sale/discovery phase. The configurator should support variation through configuration rather than custom development per client. - BPOS precedent: Feoda successfully built a more complex subscription billing solution for BPOS (a commercial client) spanning 8 companies, 6 countries, and 4 business lines — proving the platform can handle this level of complexity given appropriate iteration time.
Topic 5: RPS Payment Processing (Ash)¶
Summary: Ash walked through the RPS payment processing for both credit card and direct debit (bank/ABA).
Key Points: - Extracted to: RPS Payment Processing
Topic 6: Payment Method Changes (Pearl & Ash)¶
Summary: Discussion on how to handle a parent wanting to change their payment method after setup.
Key Points: - Extracted to: Payment Method Change Procedure
Processes Identified¶
| Process | Description | Extracted To |
|---|---|---|
| ARM End-to-End Billing Process | The 4×4 framework — complete billing lifecycle | billing-process.md |
| RPS Payment Processing | Credit card (eway) and direct debit (ABA) payment flows | rps-payment-processing.md |
| Payment Method Change | Procedure to change payment method after parent has submitted | payment-method-change.md |
Technical Insights¶
- eway is the payment service provider (payment merchant) used for credit card processing. It verifies card details, processes payments, and returns authorization codes. Code
00= successful; other codes indicate decline reasons (e.g., insufficient funds, bank hold). - ABA file is an Australia-specific bank file format for direct debit processing. The file contains school account details, parent account details, and reference codes. The format follows strict bank requirements.
- Customer deposits vs payment records: Customer deposits are created through the enrollment module (advance payments for new enrollments, e.g., year 7 and year 1). RPS always creates payment records, not customer deposits.
- Undeposited funds: Bank/direct debit payments go to undeposited funds first, then the school applies a deposit to complete the transaction. Credit card payments via eway are deposited directly.
- Suitelet authentication: Each family gets a unique URL generated from debtor code + transaction ID. Authentication methods include OTP verification (Saint Edwards, Al Faisal) and SSO via JWT token (Pymble — parents authenticate through My Pymble portal, which passes a JWT token to the Feoda suitelet).
Open Questions¶
- How will the billing configurator be redesigned to handle variations across all client types (flexible dates, fixed dates, term billing, annual billing, building levy, extracurriculars)?
- What is the plan for fixing the Al Faisal / Central SIS integration to enable the automated billing configurator?
- Should the parent payment suitelet be standardized into a single configurable version rather than per-client versions?
Source Files¶
| File | Location |
|---|---|
| Video | video.mp4 |
| Transcript (docx) | transcript.docx |
| Transcript (txt) | transcript.txt |
| Frames | extracted frames |