Modernizing TouchNet third-party sponsor billing for Ellucian SaaS
12 Aug 2026
A higher-education institution relied on a custom third-party sponsor billing process in Ellucian Banner to calculate charges covered by external sponsors and prepare billing output for its TouchNet third-party billing workflow. Moving this capability to Ellucian SaaS required rebuilding the Banner-side billing engine around Ellucian Data Connect, Ellucian’s integration platform for creating and managing data process flows.
The process handled scenarios beyond the institution’s delivered Banner third-party billing capabilities. It evaluated student eligibility, sponsor authorization, contract priorities, funding limits, eligible charges and credits, including cases where multiple contracts applied to the same student.
Modernize the institution’s custom sponsor billing capability for Banner SaaS while preserving the contract-processing behavior required to support its TouchNet third-party billing workflow.
When a TouchNet sponsor billing workflow becomes a SaaS modernization problem
The legacy solution was a custom Oracle Pro*C batch process. Pro*C is Oracle’s precompiler technology for embedding SQL in C programs, and the billing job ran through Banner Job Submission. It read Banner base tables directly, used database staging structures and internal PL/SQL packages for database-side procedural logic, applied the institution’s billing rules and produced sponsor invoice PDFs through JasperReports, a Java-based reporting engine for generating formatted outputs such as PDFs. Those outputs supported the institution’s TouchNet-related third-party billing workflow. Appworx scheduling and Banner Population Selection controlled when the process ran and which population it processed.
The customization functioned as a billing engine rather than a reporting layer. Authorization, contract limits, multi-contract sequencing, charge selection, allocations, exceptions and other decisions were distributed across custom code and database-side processing.
The institution’s custom billing behavior was tightly coupled to direct database access, database-side processing, staging tables and a legacy batch environment that could not remain the foundation of the process in Banner SaaS.
The engineering task was to identify the custom behavior the business still required, separate it from its legacy implementation and rebuild it through supported SaaS architecture patterns.
Rebuilding the billing engine around Data Connect
From direct database access to supported data sources
The new architecture uses supported API access for system-of-record data and Data Connect datasets for information that must be composed, transformed or derived. Student, sponsor, address, financial transaction and contract information can then participate in the billing workflow without direct access to Banner base tables.
This also makes previously implicit database relationships explicit. Contract relationships, financial transactions, eligibility inputs and derived billing data are assembled into structures the pipeline can evaluate and trace.
How legacy Banner data maps to the SaaS workflow
The legacy process could retrieve related data directly from Banner tables and call database-side logic within one tightly coupled execution environment. In the SaaS architecture, those responsibilities are separated according to how each type of information is obtained and used.
Legacy responsibility
Future State representation
Role in sponsor billing
Student-sponsor contract records from contract tables
Data Connect contract dataset or approved extension source
Provides the student, sponsor, contract number, term, priority, authorization status, sponsor reference, and maximum student amount needed for billing decisions
Student account charges and credits
Supported accounts receivable transaction access
Supplies transaction amounts, detail codes, posting dates, and other attributes used to determine sponsor eligibility
Student identity data
Supported student data access
Supplies institutional identifiers, names, and relevant student attributes
Sponsor and address data
Supported organization and address data access
Supplies sponsor identity and billing information required for invoice output
Contract and charge categorization embedded in database logic
Data Connect transformations
Determines which transactions qualify for a sponsor contract and derives billing values
Legacy working and staging tables
Data Connect-managed staged and tracking datasets
Stores calculated records, validation state, processing state, and downstream invoice-ready data
Internal database procedures
Explicit pipeline processing logic
Recreates authorization, prioritization, allocation, and other required billing behavior
Contract data is an important case because standard API resources do not fully represent the sponsor relationship attributes this process requires. The Future State therefore composes that information in Data Connect or exposes it through an approved extension mechanism.
The resulting data model represents the information and relationships required by the business process without reproducing the legacy table structure. Calculations and derived values move into the pipeline.
A pipeline instead of a database-driven batch program
Data Connect becomes the central processing layer for the modernized workflow:
The pipeline retrieves source data, normalizes and combines it, applies sponsor billing rules, stages invoice-ready records, generates billing output and supports downstream delivery for the institution’s TouchNet-related sponsor billing workflow. Intermediate and final state is retained for traceability, reconciliation and controlled reprocessing.
The core challenge was identifying business behavior distributed across custom code, Banner tables, staging structures and internal procedures, then expressing that behavior as explicit Data Connect processing logic.
Preserving the billing rules that made the customization necessary
Multi-contract billing still has to produce the right answer
Changing the architecture did not remove the business rules that had made the customization necessary. For each applicable student-sponsor-contract combination, the pipeline identifies eligible transactions, evaluates authorization, applies contract priority, allocates charges and credits, enforces applicable limits and calculates the resulting balance.
This becomes especially important when a student has more than one sponsor contract. Contract priority affects how credits and eligible amounts are allocated, so the workflow must maintain consistent sequencing while preventing the same billing activity from being counted more than once.
Modernizing a complex Banner customization is often a business-logic reconstruction problem rather than a code-conversion exercise.
How multi-contract sponsor billing is calculated
The calculation begins after the pipeline identifies the relevant billing population and retrieves the associated contract and financial data. From there, processing occurs at the student-sponsor-contract level.
Select the applicable contracts. Contract records are filtered for the billing term and processing population. Only active and eligible relationships proceed.
Retrieve the related financial transactions. Charges and credits are limited to students in the contract dataset and filtered according to the applicable term and sponsor billing rules.
Determine charge eligibility. Transaction attributes, including configured charge classifications, are evaluated against the contract rules so that only sponsor-eligible activity participates in the calculation.
Apply authorization logic. Contract authorization information is evaluated before the record can become a valid billing candidate.
Sequence multiple contracts. When more than one contract applies to the student, contract priority establishes the processing order.
Allocate charges and credits. Applicable credits and billing amounts are allocated according to the contract rules and priority sequence. The calculation must avoid duplicate allocation across contracts.
Apply contract limits and calculate the balance. The pipeline incorporates the maximum amount available under the contract and calculates the resulting sponsor-specific balance from eligible charges and allocated credits.
Apply run-level balance rules. Optional minimum and maximum thresholds can exclude balances outside the requested range. Zero-balance records can also be excluded unless the run configuration explicitly includes them.
Validate the invoice candidate. Required student, sponsor, contract and financial data must be present. The pipeline checks calculation consistency and verifies that the same student-contract-term combination has not produced a duplicate billing candidate.
Stage the validated result. Valid records are written to the invoice-ready dataset together with their calculated values, contract attributes, validation state, source lineage (where the data originated) and run metadata.
The resulting invoice data includes the calculated eligible charges, applied credits, total charges, total credits and balance due associated with the relevant student-sponsor-contract relationship.
Keeping billing runs controlled and traceable
The Future State also replaces database staging behavior with explicit processing state. Each run has its own identity, and records can be tracked through calculation, generation, delivery, failure and retry states.
Validation errors can be isolated without stopping the entire run. Reconciliation compares calculated billing totals with source financial data, while optional review and approval controls keep Student Accounts involved where business oversight is required.
How retries, state tracking, and reconciliation stay controlled
The pipeline separates billing calculations from the operational state required to execute them safely.
Run and record identity
Each execution receives a unique run identifier for auditability and idempotency. In this context, idempotency means a retry can recognize an already processed billing unit instead of creating a duplicate. At the record level, processing can be identified by a composite business key, a combination of fields that identifies one billing unit, built from:
student identifier;
sponsor identifier;
contract number;
billing term.
This gives the pipeline a stable way to determine whether a billing unit has already been processed and helps prevent duplicate invoice generation when a run is retried.
Processing state
A dedicated processing-state dataset records where each billing unit is in the workflow. Supported states include:
RETRIEVED
CALCULATED
GENERATED
DELIVERED
FAILED
The state record can also preserve whether a duplicate was detected, whether a retry is allowed, how many retries have occurred, the most recent attempt, the last successful step and the reason for failure.
A separate invoice-tracking dataset follows the document lifecycle after calculation. It can distinguish calculated, generated, delivered and failed invoices while retaining delivery status, document location, retry information and errors.
Partial failures and controlled retries
Validation and processing exceptions are captured at the affected record rather than automatically terminating the entire batch. Valid records can continue through the workflow while failed records remain available for review, correction or retry.
Because previous progress is persisted, retry logic can use the processing key, current status, retry count and last successful step instead of treating every rerun as a completely new billing event.
Reconciliation
The reconciliation dataset provides a financial control layer between the source transactions and the generated billing results. It can retain:
Reconciliation value
Purpose
Invoice count
Number of generated billing records in scope
Source charge total
Total eligible amount derived from source AR transactions
Billed amount total
Total calculated invoice balances
Credit total
Credits allocated during processing
Variance amount
Difference between source and billed totals
Variance indicator
Identifies differences that require attention
Reconciliation status
Tracks whether the result is verified, has a detected variance, or remains pending review
When reconciliation identifies a discrepancy, the affected result can be surfaced for review without losing the processing history that produced it.
The same control model supports validation-only runs, where calculations and checks can be performed without generating or delivering final billing output, and approval-controlled runs, where delivery waits for Student Accounts review when required.
Recreating the sponsor invoice output
The legacy process also depended on JasperReports to produce sponsor invoice PDFs. The existing JasperReports implementation could not be carried into Data Connect unchanged.
The team reproduced the required invoice-generation mechanism in Data Connect while preserving the billing information and expected output needed by the downstream TouchNet-related sponsor billing workflow. This required a separate, nonstandard technical solution. We cover the reporting reconstruction in a separate technical deep dive on recreating JasperReports-style PDF generation in Ellucian Data Connect.
A SaaS-ready billing workflow with controlled financial processing
The modernized solution moves the institution’s sponsor billing capability away from direct Banner database access, Pro*C execution, legacy staging tables and internal database procedures. Contract evaluation and billing calculations now run within a Data Connect-centered architecture built around supported data access and explicit processing logic.
Operational controls are also part of the Future State architecture. Processing state supports duplicate prevention and retries, validation isolates problematic records, and reconciliation connects calculated billing results back to source financial activity. Sponsor invoice generation and delivery remain part of the same controlled workflow.
The institution retained the custom sponsor billing capability its business required, now implemented through a Banner SaaS-compatible architecture that continues to support its TouchNet-related sponsor billing workflow.
Frequently asked questions about modernizing custom Banner sponsor billing
What role does TouchNet play in the modernized sponsor billing workflow?
TouchNet is part of the downstream third-party billing context for this integration. The modernization focuses on the Banner-side logic that determines eligible charges, applies contract rules and prepares sponsor billing output. Data Connect replaces the legacy database-centric processing while supporting configurable downstream delivery for the TouchNet-related workflow. The project does not require TouchNet itself to be reimplemented as part of the Banner modernization.
Why couldn’t the legacy sponsor billing process move to Banner SaaS unchanged?
The issue was the institution-specific customization. The custom process depended on direct Banner database access, Pro*C processing, database staging structures, internal PL/SQL packages and the legacy Job Submission environment. The required business behavior therefore had to be separated from those implementation dependencies and rebuilt through SaaS-supported mechanisms.
Can complex multi-contract sponsor billing still be handled without direct database access?
Yes. The required student, sponsor, contract and financial data can be assembled through supported APIs, Data Connect datasets and approved extension mechanisms. Data Connect transformations can then apply authorization, eligibility, priority sequencing, credit allocation, limits and balance calculations without direct access to Banner base tables.
What happens when required contract data is not available through standard Ethos APIs?
Ellucian Ethos provides the API integration layer used across Ellucian systems, but standard resources do not expose every contract attribute required by this billing process. Contract relationships can therefore be composed in a Data Connect-managed dataset or supplied through an approved extension mechanism. This is particularly important for attributes such as contract number, priority, authorization status, sponsor reference information and maximum student amount.
How does the modernized process prevent duplicate invoices during retries or partial runs?
Each execution has a unique run identifier, while processing records use a business key based on the student, sponsor, contract and billing term. Persisted processing state records whether the item has already been handled, its current lifecycle status, retry eligibility and previous attempts. These controls allow repeated or partial runs to distinguish valid retries from duplicate processing.
How are billing discrepancies and failed records handled?
Validation problems can be captured against individual records so that one exception does not automatically terminate the entire run. Reconciliation compares source financial totals with calculated sponsor billing totals and records variances for review. Processing and invoice-tracking data preserve the state and errors needed to investigate or retry affected records.
What happened to the legacy JasperReports invoice generation?
The sponsor invoice remained a required part of the process, but the JasperReports-based implementation could not move into Data Connect unchanged. The team reconstructed the required invoice output using Data Connect capabilities. A companion technical deep dive covers how the existing report was analyzed and reproduced, including the PDF-generation challenges involved.
Modernize custom Banner processes for SaaS
Custom Banner jobs that support external platforms such as TouchNet often contain institution-specific financial rules, integrations, operational controls and years of business decisions that still matter after a SaaS transition.
ABCloudz can help you identify the behavior your institution needs to retain, separate it from unsupported legacy dependencies and rebuild the process using Ellucian Data Connect and other supported architecture patterns. Contact ABCloudz to discuss your Banner SaaS modernization project.
