Modernizing custom Banner student billing with TouchNet for Ellucian SaaS

Runtime inputs and governed configuration

The future workflow separates values that change for a specific billing run from rules that should be maintained as configuration.

Governed configuration holds rules such as charge-category mappings, memoed-aid and authorized-aid inclusion logic, payment-plan rules, address priorities, population-selection rules, output formatting and lockbox construction.

Processing the selected student population

The billing calculation pipeline follows a controlled sequence.

1. Validate the run context.
   The workflow validates the academic period and other required execution parameters before processing students.
2. Resolve the population.
   The population can come from all eligible students, an external dataset, configured filters or one identified student. Include and exclude rules can narrow the population further.
3. Retrieve billing-relevant activity.
   For each student, the pipeline obtains identity context, receivable transactions, account information, authorized aid and memo-related activity from the SaaS-accessible source set.
4. Normalize financial activity.
   Detail codes and transaction characteristics are mapped into the business categories required by the billing process, including charges, payments or credits, miscellaneous activity, deposits, authorized aid and memoed aid.
5. Evaluate deposits and aid independently.
   Deposit balances are derived from deposit-related transaction activity, and only positive remaining balances are carried forward. Authorized aid is evaluated under its governed eligibility rules. Memoed aid is evaluated separately using memo detail codes, expiration dates, billing indicators and timing rules.
6. Calculate the billing result.
   The pipeline derives the values required downstream, including previous balance, balance till date, amount owed, adjusted due, minimum due and relevant statement indicators.
7. Apply inclusion rules.
   Minimum and maximum amount-due thresholds and other configured conditions determine whether the student is included in the billing output.
8. Create the canonical record.
   An included student is written to Ellucian Data Connect, the integration platform used here to hold the handoff between calculation and rendering, as a canonical billing record containing the financial result and the context required for statement generation.
9. Produce run-level evidence.
   The pipeline records processed, included, excluded and failed counts, aggregate billed amounts, execution status and trace information for reconciliation and operational review.

A simplified representation of the decision flow is:

selected student

    ↓

retrieve receivable and aid data

    ↓

categorize financial activity

    ↓

evaluate deposits

    ↓

evaluate authorized aid

    ↓

evaluate memoed aid

    ↓

calculate billing values

    ↓

apply amount and inclusion rules

    ↓

included?

   ↙     ↘

 yes     no

  ↓       ↓

canonical  exclusion recorded

billing

record

This separation makes the business rules explicit. The future workflow no longer depends on the physical structure of the legacy Banner tables to define how billing should behave.

The canonical dataset creates an explicit data contract between the two stages of the solution.

Run and selection context

Each run carries enough context to identify how and why the record was produced, including:

• run identifier and generation timestamp;
• billing mode and processing status;
• academic period;
• selection and billing dates;
• amount thresholds;
• population-selection context.

This preserves information that would otherwise be implicit in a batch session or temporary database state.

Student and financial context

A sanitized representation of the handoff looks like this:

{

  "runContext": {

    "runId": "<run-id>",

    "generationTimestamp": "<timestamp>",

    "billingMode": "<mode>",

    "processingStatus": "<status>"

  },

  "selectionContext": {

    "populationFilterType": "<ALL | DATASET | FILTERED | SINGLE>",

    "academicPeriod": "<academic-period>",

    "billingRunDate": "<date>",

    "assessmentDate": "<date>"

  },

  "studentRef": {

    "personId": "<synthetic-person-id>",

    "studentId": "<synthetic-student-id>",

    "academicPeriod": "<academic-period>"

  },

  "billingSummary": {

    "previousBalance": "<calculated-value>",

    "currentTermCharges": "<calculated-value>",

    "currentTermCredits": "<calculated-value>",

    "depositBalance": "<calculated-value>",

    "authorizedAidAmount": "<calculated-value>",

    "memoedAidAmount": "<calculated-value>",

    "balanceTillDate": "<calculated-value>",

    "amountOwed": "<calculated-value>",

    "adjustedDue": "<calculated-value>",

    "minimumDue": "<calculated-value>"

  },

  "transactionDetails": [],

  "authorizedAidDetails": [],

  "memoedAidDetails": [],

  "depositDetails": [],

  "statementFlags": {},

  "addressContext": {},

  "audit": {}

}

The record can carry several types of downstream information:

This contract defines ownership clearly. The calculation stage determines the financial result. The rendering stage consumes that result and adds presentation data without redefining it.

Separating rendering from calculation does not remove the institution-specific statement behavior. Several detailed rules remain part of the future state.

Address selection follows a configured hierarchy

The statement pipeline does not assume one fixed address type. It evaluates address types in configured priority order.

configured address priority

        ↓

first address type

        ↓

matching valid address?

   yes ↙       ↘ no

select            next priority

address               ↓

                 repeat lookup

                      ↓

             no valid address found

                      ↓

          institutional fallback address

The selected address is then formatted for the statement. Street lines, city, state, postal code and country are handled according to the output rules, with the default institutional address used only when no valid student address is available.

Transaction dates preserve the required display behavior

The displayed transaction date does not always come from the same source field. The future logic preserves the legacy business rule:

if transaction bill date == statement billing date:

    display transaction date or activity date

else:

    display effective date

This small implementation rule has visible consequences. Replacing it with a generic date mapping could change the ordering or dates students see on their statements.

Lockbox output retains the downstream data contract

The lockbox scanline remains a fixed-format structure:

The identifier is normalized when required by the downstream format. The balance is converted to the required cents representation, and the final check digit is calculated with the required modulo-10 checksum logic.

The rendering stage also preserves fixed-width statement requirements such as student boundary markers, page breaks, mailing-block placement, continuation handling for long detail sections and configured transaction ordering.

These rules explain why statement rendering remains its own engineering responsibility. The financial values come from the canonical dataset, while presentation and downstream compatibility for TouchNet electronic billing and DATAMATX paper billing are controlled separately.