Operation Data and Payment Plan

Once a customer has gone through prequalification, the simulator asks the seller for the terms of the sale, builds a payment plan from them and lets the seller adjust it before saving. It takes two steps and ends on a summary. In the operation data step the seller enters the amount, the rate and the dates. In the payment plan step the seller reviews and edits the installments while AltScore prices each one. The summary appears once the simulation is saved.

The seller does all the typing, but much of what the screen allows is set by the operator in the Hub: where the maximum term comes from, how the branch is entered, whether the origination fee is financed, the default rate and the organization's own rates. Those settings live under Settings > Configuration > Seller portal and are covered in Configuring the Portal. This page names each one where it changes what the seller sees.

The steps are numbered by their position in the simulator. When the simulator includes prequalification, it is always step 1, so these two are steps 2 and 3, and the examples below use those numbers. Without prequalification they are steps 1 and 2.

Step 2: Operation Data

The step opens with the heading Step 2 · Operation details (on desktop), the title Enter the details to simulate and the customer's name under it. On desktop, a Back to the result link returns to the prequalification result when there is one, unless the seller is editing a saved simulation.

The form has three parts: the operation, the financial terms and the payment plan.

The Operation Block

The Operation block identifies the sale in the seller's own systems.

Operation number is optional. Its hint explains what it is for: "The id this operation has in your system. If it matches one of the customer's deals, the simulation is filed under it." When the simulation is saved, AltScore looks the number up among the organization's deals. If exactly one deal carries it and that deal is this customer's, the simulation is linked to it. If no deal has it, several have it, or it belongs to another customer, the simulation is saved anyway without a link, and the summary says why (see The Save Warnings). If the seller leaves the number empty, nothing is looked up and no warning appears.

Operation date defaults to today. Branch number works in one of two ways, chosen in the Hub under Branch number:

The distributor list covers the distributors of the seller's routes, or every distributor of the organization when the prequalification search scope is set to the whole organization. Distributors without an External ID are left out. The list is sorted by name, holds up to 500 entries, and shows Loading distributors… while it loads. When there is a single distributor, it comes preselected. If the list is empty or cannot be loaded, the field turns back into free text, and a hint asks the seller to type the branch number by hand: "There are no distributors to choose from: type the branch number by hand." or "We could not load the distributors: type the branch number by hand."

Financial Terms

The Financial terms block holds the numbers the plan is priced on.

The products offered are only the custom-amortization products of the organization's credit partner. Each one arrives with its rates already resolved in the same order the save uses (see How the Plan Is Priced), so what the screen shows and what gets saved agree. While the products load, the block shows Loading products…. If there are none, it shows No own-financing products are enabled.

The default rate. When the operator sets a Default TNA in the Hub, the rate field opens with that value, but only if the field is empty. The help line changes to "Default rate set by the lender; you can change it." The seller can change it, and the plan is priced with whatever rate the seller leaves. The rate is never checked against the product.

Terms Box

Below the financial terms, a Terms box shows two conditions the seller does not choose, and holds the plan inputs described in the next section.

Maximum term appears as a number of months, for example 36 months, and is read-only, except when the Hub lets the seller type it, in which case it becomes a number field. Origination fee appears as a read-only percentage. The note in the box reads: "The term and the origination fee are set by the lender and cannot be edited by the dealership." When the seller types the term, the note reads instead: "The origination fee is set by the lender and cannot be edited by the dealership. The maximum term is yours to enter."

Where the maximum term comes from is the Hub setting Where the maximum term comes from:

When the chosen source has no value, the product's term applies, and failing that, 36 months. Steps 2 and 3 resolve the term with the same rule, so the plan is never built against one limit and checked against another.

Plan Inputs

The Payment plan part, inside the same box, asks for Number of installments (default 6) and Frequency: Monthly, Quarterly, Biannual or Annual, with Biannual as the default.

The number of installments is capped at the smaller of 20 and the maximum term divided by the frequency's months. An 18-month term at a biannual frequency allows 3, and the hint says so: Up to 3 with an 18-month term. Changing the frequency or the term lowers the count when the old one no longer fits.

A green line under the inputs summarizes the plan. With the defaults and an issue date in April 2027, it reads "6 biannual installments, the last one in April 2030." A single installment reads "A single installment, due in October 2027." Before the issue date is set, the line names only the number of installments and adds "Enter the issue date to see the final due date."

Validation

Generate amortization schedule checks the form before moving on. Errors appear under each field, and the screen scrolls to the first one.

The button stays disabled while the products load, when it reads Loading products…, and when there is no product to choose.

Back returns to the previous step. It is hidden while the seller is editing a saved simulation, because prequalification does not run again in that case.

Step 3: The Payment Plan

Step 3 opens with the plan already built. The capital is split evenly to the cent, and the last installment absorbs any rounding. Due dates fall at the issue date plus one, two, three... periods of the chosen frequency. When that day does not exist in the month, the month's last day is used, so 31 January plus one month is 28 or 29 February. If the seller entered no amount, the plan starts with a single row, one period after the issue date.

The plan is built only when none exists yet. A seller who goes back to step 2 and returns finds their manual edits still in place.

What the Screen Shows

The step shows the heading Step 3 · Simulation (on desktop) and the title Payment plan. Once a calculation is available, four figures appear above the table: Principal to amortize, Interest, Plan (for example, 6 installments) and Total to pay.

Below them is the Installments table. The seller edits two columns, and AltScore calculates the rest:

Each row has a delete button. It is disabled when only one row is left. A dark Totals row closes the table, and a footnote gives the currency, for example "Amounts in USD."

Editing Tools

Three buttons sit above the table:

Cells the seller edited by hand are highlighted in green. The note under the table spells out the trade-off: "Rebuild the plan" lays out even installments again from the conditions and discards the cells edited by hand. The note always ends with "Up to 20 installments."

Blocking Problems

A banner above the table shows one blocking problem at a time, in this order. While any of them holds, the plan cannot be saved.

1. Due dates out of order. Each due date must come after the one before it, and the offending date turns red. "Some due dates are out of order: each date has to come after the previous one."
2. The amount is above the approved limit. This applies only when the prequalification published a limit. "The amount financed ($130,000.00) is over the approved credit limit ($120,000.00)."
3. The capitals do not add up to the target. The banner gives the missing or excess amount and offers Split evenly as a shortcut. "$5,000.00 still to assign: the installment capitals have to add up to $120,000.00." or "$5,000.00 assigned too much: the installment capitals have to add up to $120,000.00."

What the target is. Normally the capitals must add up to the amount financed, and the origination fee is charged at signing. The note under the table then reads, for example, "The installment capitals have to add up to $120,000.00." When the operator turns on Finance the origination fees in the Hub, the fee joins the capital and is paid across the installments, so the capitals must add up to the amount plus the fee. The note under the table says so, for example "The installment capitals have to add up to $121,800.00: the amount financed plus the origination fee."

Live Calculation

Interest, VAT and totals are calculated by AltScore half a second after the seller stops editing, and only when every row has a due date and a capital and the capitals add up to the target. The calculation stores nothing: it is a quote, not a save.

While it runs, Calculating… appears and the calculated columns dim. Next to the save button, "There are unsaved changes to calculate." signals that the numbers on screen are older than the last edit. Before the first calculation, the table reads "Fill in the installments to see the calculation.", or "The sum of the capitals must match the amount financed." when the capitals are off.

Installments That Need Authorization

An installment that falls more than 30 × (maximum term + 4) days after the issue date needs credit authorization. With a 36-month term, that is any installment more than 1,200 days out. The row shows an amber warning icon next to its months. The icon has no visible text: screen readers announce it as "Requires credit authorization". An amber notice appears under the table: "At least one installment requires credit authorization before approval." This flag does not block saving. It travels with the simulation and is printed on the document.

How the Plan Is Priced

AltScore prices the plan with one set of rules, used the same way in the product list, the live calculation and the save.

Where Each Rate Comes From

The annual nominal rate is always the seller's input. The other three rates are resolved field by field, in this order:

The organization's rates are the Your organization's rates block in the Hub: VAT on interest, VAT on refinancing, Origination fee and Default TNA. A field left empty there passes the decision to the product. A product whose VAT on interest is 0 counts as not configured, so the built-in 10.5% applies. This applies only to VAT on interest: a product's VAT on refinancing of 0 is used as 0, and so is a product's origination fee of 0 or a 0 entered in the Hub.

The Formulas

This is simple interest on balance, counted in actual days over 365. The printed document states the same thing in its conditions box.

A worked example with made-up figures: an installment of 60,000 due 180 days after the issue date, at an annual nominal rate of 30%. The interest is 60,000 × 0.30 ÷ 365 × 180 = 8,876.71, rounded up to 8,877. The VAT at 10.5% is 932.085, rounded up to 933. The installment total is 69,810. On an amount financed of 120,000, a 1.5% origination fee is 1,800.

What the Calculation Refuses

AltScore rejects a plan with an amount that is not above zero, a negative rate, a maximum term that is not above zero, fewer than 1 or more than 20 installments, a capital that is not above zero, or due dates that are not strictly ascending or not after the issue date. The capitals must add up exactly to the amount to amortize. The portal catches most of these before it sends anything, so a seller usually meets them as the banners above. Two are not caught on screen: a first due date on or before the issue date, and an installment whose capital is zero or negative while the total still adds up. Those reach the calculation, and the refusal appears as a message under the table instead of as a banner. The plan cannot be saved until the row is fixed. The error texts are listed in Errors, Warnings and Limits.

Saving the Simulation

Save the simulation (Save changes when editing) is enabled only when there is an up-to-date calculation, no blocking problem and an identified customer. Back to customer details, at the top of the step on desktop, returns to step 2 without saving. On a phone, a Back button next to the save button does the same.

After saving, the simulator moves to the summary. If the seller goes back and saves again, the same simulation is updated, not duplicated.

Approval is covered in Own Financing in the Hub.

What Gets Saved

The seller can only save for a customer they can reach. If the operator turned off Allow continuing anyway in the Hub (see Prequalification), saving a new simulation is also refused unless it carries an acceptable prequalification result, with "Your configuration requires a pre-qualification before saving the simulation. Go back to the pre-qualification step and validate the customer." With the save, AltScore records who did the selling: the seller, the route that customer shares with the seller (the first one when there are several), and that route's distributor.

The simulation stores the customer, the product, the amount, the maximum term, the annual nominal rate, whether it is a refinancing, the issue date, and every installment's due date and capital. It also stores the operation number and date, the branch, and the linked deal when there is one. From prequalification it keeps the result: the decision, whether it was approved, which run produced it and the report link. The organization's own systems can attach an optional block of extra data of their own.

The frequency is not stored. It only shapes the plan the portal generates. When a saved simulation is reopened, the frequency is inferred from the gap between its first two due dates, or falls back to the default.

The Save Warnings

Some problems do not stop the save, but the seller should know about them. When the save comes back with warnings, the summary opens with an amber box titled Your company applied its own terms that lists them. A warning never undoes the save.

The term warning. When the maximum term (from the product, or fixed in the Hub with Set here) is shorter than the plan, the save still goes through. The plan is checked both against the term entered and against the schedule's real length in calendar months, rounded up. The plan is saved exactly as built, and the warning box flags the difference so someone can review it. Despite what the warning says, the plan and the term are saved as the seller built them: nothing is replaced with the product's term.

The Summary

The summary is where the seller lands after saving. Its title is Operation summary, followed by the Simulation ID and a Copy button that briefly reads Copied.

A ledger recaps the operation:

The Contract block has a Print or save as PDF button. It first loads the saved simulation, showing Preparing the document… while it does, and then opens the browser's print dialog, where saving as PDF is one of the options. If loading fails, it shows "We could not prepare the document." What the document contains is described in Saved Simulations and History.

The What comes next block lists three steps for the customer. They are for information only, and the portal does not track them.

The summary also holds the onboarding card, unless the operator turned Send the bot to the customer off in the Hub (covered in Customer Onboarding), and the actions the operator configured, covered in Simulation Actions. It ends with two buttons: Back to start opens a blank simulator, and View simulation opens the saved simulation's detail.

Things to Know

Rates follow the organization first. Where the organization has a rate set in the Hub, it wins over the product, field by field. The product's rate applies only where the organization left the field empty, and the built-in default applies where both are empty. The Your organization's rates block is visible in the Hub only while The seller must pick a product is off. Rates entered there stay in effect after the switch is turned back on. The hint next to that block in the Hub reads "Used when no product is picked. With a product picked, the product wins.", which is not how the rates are applied: the organization's rates apply even when a product is picked.

The default rate is only a starting point. Default TNA fills an empty field and nothing more. Whatever rate the seller leaves is the one the plan is priced with and the one saved.

An empty operation number means no deal link. The deal is found by the operation number alone. Without one, the simulation is saved without a deal, no warning appears, and actions that run on the deal cannot run (see Simulation Actions). An operation number also cannot be reused: if another simulation of the organization that has not been discarded already has it, the save is refused with "That operation number is already used by another simulation."

The frequency is a drafting aid. It shapes the generated plan and caps the number of installments, but it is not stored. A plan edited by hand into uneven gaps reopens with whatever frequency its first two due dates suggest.

Flags inform, they do not block. An installment that needs credit authorization and a plan longer than the maximum term both save normally. The first is marked on the plan and the document. The second appears in the warning box on the summary. Both are left for review before approval.

Coming back keeps the work. Step 3 builds a plan only when there is none, so moving between steps keeps manual edits. Rebuild the plan is the only way to start over from the conditions, and it discards those edits.

Unsaved work lives only in the open tab. The simulator is not saved in the browser. If the seller reloads the page, closes the tab or opens the link again before pressing Save the simulation, the operation data and any hand-edited installments are lost.