The enrollment agreement and the payment plan, from the same deal

Why does the agreement say one thing and the plan charge another?

Because they were built twice. Admissions fills in the enrollment agreement in a signing tool, typing the program price, the deposit and the payment dates by hand. The business office then builds the payment plan somewhere else, from the deal or from a spreadsheet, typing the same numbers again.

Two copies of the same numbers drift. A start date moves after the agreement went out. A fee is added to the plan but not to the agreement. A deposit is $1,500 on one and $1,200 on the other. Nobody notices until a student disputes a charge and someone opens the signed PDF.

What has to be on the agreement for a plan?

The agreement is what you point to when a payment is missed or disputed, so it has to carry the plan itself, not a summary of it. What a payment plan agreement should cover lists the sections. For a tuition plan, the ones that drift are:

• The total, and what it is for: the program, by name.
• The deposit, and the date it is due.
• Each payment: how many, how much, and the date of every one, not "monthly from the start date".
• How each payment is taken: card or bank account, and whether it is charged automatically. If the plan debits a consumer's bank account automatically, the authorization has to be signed or similarly authenticated (12 CFR 1005.10(b)).
• The card fee, if you add one where your state allows it, so the student sees it before signing and again at checkout.
• Refunds and withdrawal, in your school's words.

How do you build both from one record?

Start from the deal. The deal already holds the student, the program, the price and, once the plan is built, the schedule. If the agreement is generated from the deal too, with the schedule merged in as a table, there is one copy of the numbers.

The order matters:

1. Build the plan on the deal first: deposit, number of payments, dates.
2. Generate the agreement from the deal, so the schedule table is filled in from the plan, not typed.
3. Send it for signature, and lock the copy that went out. If anything changes after that, send a new version and void the old one, rather than editing a document someone has already read.
4. Take the deposit after the signature, from the same page or the same link, so the student never signs one set of terms and pays against another.

What should the signed record hold?

Enough to answer a dispute without a phone call:

• The copy that was signed, unchanged since it was sent.
• Who signed, the name they typed, when, and from what device and address.
• How you knew it was them. A link alone can be forwarded. A code sent to the student's email, entered before they can sign, ties the signature to the address on file.
• What they agreed to, in the exact words of the consent they ticked, including consent to sign electronically.
• Your countersignature, if your accreditor or state asks for one, with its own date.

Keep that record on the same deal as the plan, so a missed payment, the agreement and the plan's history sit together.

What happens when the plan changes?

A plan changes at least once for many students: a moved date, a split payment, a smaller amount for the rest of the plan. Changing a payment plan after it starts covers how to make the change. On the agreement side, the rule is the same: don't edit a signed document. Issue a revised agreement that replaces the first, void the original, and record which one is current. If the student pays by automatic bank debit and the amount changes, give written notice of the new amount at least ten days before it is taken (12 CFR 1005.10(d)).

Sources

• Regulation E, 12 CFR 1005.10, preauthorized transfers: https://www.consumerfinance.gov/rules-policy/regulations/1005/10/
• E-SIGN Act, 15 U.S.C. 7001: https://www.law.cornell.edu/uscode/text/15/7001