Plan multiple variants on one offer

A variant (also called an "option") is a self-contained planning package inside an offer: its own bill of materials, its own pricing, its own financing terms, and its own 3D plan. One offer carries one or more variants. The customer either picks one of several to sign, or you send a single recommended variant for direct signature. Reach for variants whenever you want the customer to choose between scenarios while keeping the comparison in one place.

Who this is for

• Account managers building offers that present the customer with a choice between scenarios.
• Installer admins setting up the offer template, default planning mode, and which variant types your team uses.
• Anyone editing an offer after a partial signature. Variants are also how you handle post-signature add-ons while keeping the original signed package intact.

Before you start

• The offer must already exist. Every variant lives inside an offer, so create the offer first if you haven't yet.
• The offer should be not yet fully locked. You can add variants after a signature lands on one variant, and the signed variant itself stays as the customer agreed to it.
• Decide whether the new variant should start empty or duplicated from an existing one. Duplicating preserves the solar layout, line items, payment mode, financing details, subsidies, and optional component bundles. It's the right starting point unless the scenarios diverge from the first module.
• For a financing variant (Bees & Bears, EOS, or similar), confirm the relevant per-user right is on. A financing variant is created via a separate flow on top of an existing cash variant. Duplicating an existing financing variant keeps it a financing variant of the same flavour: duplicate a Bees & Bears or EOS variant and the copy comes back with the same financing provider (and EOS mode) ready to tweak.

What a variant is, and what it isn't

A variant is a complete planning package. Each variant carries:

• Its own bill of materials (modules, inverters, batteries, wallboxes, heat pumps, additional components).
• Its own prices (component prices inherited from the components catalog, with offer-level adjustments).
• Its own financing terms, if it's a financing variant.
• Its own 3D plan (modules placed, strings wired, simulation snapshots).
• Its own PDF when the offer is generated.

A variant is more than a payment-mode flip of another variant. To show the customer "the same package, with financing", create a separate financing variant from the cash variant. It carries a different scope, a different bill-of-materials surface, and different terms.

Duplicate an existing variant

Use this when the new variant shares most of its planning with an existing one. It's the recommended starting point.

1. Open the offer in the Portal.
2. Open the Variants overlay at the top of the offer page.
3. On the variant you want to copy, click Duplicate (often in the three-dot menu next to the variant).
4. Give the copy a clear name: PV only, PV with battery, PV with battery + heat pump. Naming matters once you have three or more variants on the offer.
5. The duplicate appears in the list with the next available variant number. Open it and adjust: remove the battery, add the heat pump, swap a module type.

The duplicate inherits the source variant's solar layout (modules, strings, parallel groups), line items, payment mode per component, financing details, subsidies, optional component bundles, and the solar-yield and economics inputs. Edits on the duplicate stay independent from the source from the moment of creation.

If the variant you duplicate is itself a financing variant (Bees & Bears or EOS), the duplicate keeps the same financing flavour: same financing provider, same EOS mode, same "using financing provider" setting. That makes "duplicate, then tweak the components or the term" the fast way to spin up a second financing scenario. For a cash copy of a financing variant, duplicate it and then remove the financing on the copy.

Create a blank variant

Use this when the scenarios diverge from the first module. For example, a "PV only" variant on the south roof versus a "PV + carport" variant that needs a different building setup.

1. Open the offer in the Portal.
2. Open the Variants overlay.
3. Click Create new variant (the button at the top of the overlay).
4. Enter a name and confirm.
5. Open the blank variant and plan it from scratch: pick a planning mode (the default comes from your workspace's preferred mode), draw the roof, place modules, set components.

The blank variant starts with no components, no plan, and no carry-over from the offer's other variants.

Name your variants well

The customer reads variant names, so make them earn their place. Two practical rules:

• Name by content, not number. "Variant 2" tells the customer nothing. "PV + battery" tells them exactly what to compare. Every variant gets a per-offer number (1, 2, 3, ...) automatically. The name is yours.
• Keep the naming scheme consistent across the offer. If you start with PV only and PV + battery, keep the language, capitalisation, and pattern aligned for the third (rather than switching to Mit Wärmepumpe).

When you generate the offer PDF, the variant name is what the customer sees beside the package details and pricing.

Edit a variant's bill of materials

Every variant has its own bill of materials. Once a variant exists, you edit its components inside the offer's Planning view, the same flow as a single-variant offer, scoped to the selected variant.

1. Open the offer, open the Variants overlay, and click the variant you want to edit.
2. Go to the Planning view.
3. Add, remove, or change components: modules, inverters, batteries, wallboxes, heat pumps, additional components, optional bundles.
4. Adjust per-component payment modes (Purchase, Lease, or Financing) where the option matters.
5. Save. The variant's pricing recomputes, the simulation re-runs, and the PDF picks up the new state when you next generate it.

Each variant keeps its own state. To keep two variants in sync (for example, cash and financing versions of the same package), mirror the edits on each.

Edit a financing variant's bill of materials

A financing variant (Bees & Bears, EOS, or similar) is created by a separate financing-setup flow that copies the cash variant's bill of materials and adds the financing terms. Once created, it's an independent variant with its own components, and you edit it the same way as any other variant.

A few specifics for financing variants:

• Financing terms recompute on every BOM edit. Add a component and the loan amount goes up, the monthly rate goes up. Verify the financing-side numbers after each component change. The customer sees them on the financing variant's PDF.
• Optional component bundles carry across to the financing variant. Creating a financing variant copies the cash variant's optional bundles onto the financing variant. They land un-ticked, so the customer re-selects the ones they want. To start the financing variant without them, remove them after creation.
• Duplicating a financing variant keeps it a financing variant. Duplicate an existing financing variant (rather than financing a cash variant) and the copy inherits the source's financing provider and EOS mode. You get a second financing variant of the same flavour, ready to adjust components or term. To turn it back into a cash variant, remove the financing on the duplicate afterward.
• Keep the cash and financing variants aligned manually. Two practical patterns work well: finalise the cash variant first and then create the financing variant from it, or edit both variants in parallel and double-check via the variants overlay that the line items match.
• Pricing changes reach the financing partner after signature. Pre-signature BOM edits affect the customer-facing offer PDF. The financing-partner submission happens once the customer signs.
• The margin badge shows on cash variants only. A cash variant shows a margin badge. A financing or lease variant shows N/A, because a financing variant's economics come from the partner's loan quote (rate, term, interest), so a straight sale-price-minus-cost margin isn't meaningful for it. The cash variant beside it shows its margin as usual.

For a deeper walkthrough of financing variants, contact your Reonic account manager.

Use different components per variant

A variant carries any combination of components, which is the whole point. Three common patterns:

• Different battery sizes. Same PV layout on every variant, but a 5 kWh battery on variant 1, 10 kWh on variant 2, 15 kWh on variant 3. The customer sees the production curve, self-consumption, and payback for each storage size in one offer.
• With and without heat pump. A "PV only" variant and a "PV + heat pump" variant. The simulation pulls the heat pump's load profile into the variant that has one.
• Different module brands or wattages. Same roof, same string layout, but glass modules on one variant and all-black modules on another, at different price points.

Each component is per-variant. Switching a module type on variant 1 leaves variant 2 untouched.

Adjust pricing and discounts per variant

Pricing happens at the variant level. Each variant has its own line-item prices (inherited from the components catalog on insertion) and its own discount or surcharge handling.

• Component prices come from the components catalog when the component is added to the variant. Edit them per-variant after insertion if a specific scenario justifies a different price.
• Variant-level discounts apply to the totals on that single variant.
• Offer-level discounts (if your workspace uses them) apply to whichever variant the customer ultimately signs. The behaviour depends on how your offer is configured, so verify on a test offer before you run a multi-variant offer through signature for the first time.

The variants overlay shows the total price per variant once components and prices are set, so you can compare at a glance before sending.

Configure optional component bundles per variant

Optional component bundles are upsell items the customer ticks on at signing: an EV charger upgrade, a premium monitoring package, or extra panels.

• Bundles are configured per-variant. Variant 1 can offer "add a wallbox for €1,200" while variant 2 doesn't.
• When a customer signs a variant with optional bundles, the ones they ticked become part of the signed scope. The ones they left unticked stay out.
• Bundles carry across on variant duplication. Duplicate a variant that has optional bundles configured and the duplicate starts with the same bundles. They land un-ticked, so the offer to the customer is preserved while the previous selection is not. The duplicate dialog confirms this with "Optional components are duplicated".

To drop a bundle on the copy, remove it after duplicating.

Compare variants

Side-by-side comparison happens on the offer page, not inside the 3D editor. The simulation runs per-variant, and the offer page surfaces the KPIs in a table.

• Profitability comparison. Break-even year, IRR, and total savings show per variant. The customer (and you) can see whether the battery pays back in 7 versus 12 years.
• Energy-flow comparison. Annual production, self-sufficiency rate, self-consumption rate, and grid feed-in volume show per variant. The "no battery" variant typically shows lower self-sufficiency and higher feed-in than the "with battery" variant. The full PV yield / production forecast (Ertragsprognose) for the active variant lives on the offer's Simulation > Production PV view. That's where annual and monthly production curves, capacity-factor breakdowns, and the weather-adjusted yield numbers are surfaced. The comparison table on the offer page pulls the headline numbers from that simulation.
• PDF comparison. The generated offer PDF can show multiple variants side by side when your PDF template is configured for it. Otherwise each variant gets its own section.

To compare two roof layouts side by side (different building geometry, not just different components), use variants too. Each variant carries its own 3D plan.

Send a multi-variant offer to the customer

When you send the offer for signature, you choose which variants to include in the customer's view.

1. From the offer page, start the signature request flow.
2. Tick the variants you want the customer to see. Working copies, test variants, and parked scenarios stay behind.
3. Send. The customer receives a single offer with the included variants and chooses one.

The customer compares the included variants and signs one of them. The variants they don't pick remain on the offer record as alternatives.

The full walkthrough of the signature flow (signature method, single-link versus multi-recipient, and so on) lives in the offer-signature guide. This section covers the variant-selection step.

Pro tip: To keep a variant off the customer's view without deleting it, leave it unticked when you start the signature request. It stays on the offer for your internal reference, and the customer's link won't include it.

Handle other variants after signature

A signed variant is locked. Every editor (Plan3D, components, pricing, financing) becomes read-only on the signed variant. The variants the customer didn't pick stay editable on the offer record, so you can keep iterating on them if the customer comes back to revisit.

• The signed variant stays as signed. To change a signed scope, fork it to a new variant (see below).
• Other variants on the same offer stay editable. Update them, archive them, or use them as the basis for new variants. They're independent of the signed variant.
• Add new variants after a signature. This is the standard way to handle post-signature add-ons. The customer signed a "PV only" variant and a month later wants a battery: add a new "PV + battery" variant (often duplicated from the signed variant), edit it, and run a fresh signature request.

Fork a variant after signature

Forking a variant means duplicating it as the starting point for a new variant. The three most common cases:

• Post-signature add-ons. The customer signed and now wants a wallbox or a heat pump. Duplicate the signed variant into a new editable variant, add the upgrade, and send a fresh signature request on the new variant. The original signed variant stays untouched, so the historical record is preserved.
• Installation-specific edits. When you start the installation on a signed offer with multiple variants, you can create an "Installation:" variant that forks the signed variant into an installation-time editable copy. The installer can tweak details that came up during the install (cable runs, additional materials) while the signed customer record stays as agreed. This is a separate workflow, covered in the installation transition guide.
• Upgrading an existing PV system. To add to or modernise an array that's already on the roof (new inverter, additional modules, re-string), model the existing array using the existing-system planning fields. Create a normal variant, enter the existing system through the existing-system fields, then plan the additions on top. Set the relevant feed-in tariff on the variant's Planning > Solar > Solar parameters (the Feed-in tariff field) if a different tariff applies to the existing system versus the new build. To compare "keep current setup" versus "upgrade" for the customer, create two variants and compare KPIs on the offer page.

Forking creates an independent variant. Once forked, edits on the new variant and the original stay separate.

Edit or unlock a greyed-out variant

A greyed-out, read-only variant is signed. You have three options:

1. Withdraw the signature if the customer hasn't actually agreed yet (you sent for signature but the customer pushed back). This re-opens the variant for editing. Withdraw-or-expire behaviour depends on how your offer is configured.
2. Fork the variant by duplicating it into a new editable variant and continuing work there.
3. Review it read-only by opening the variant to see what was signed. The PDF, the plan, and the components stay viewable.

The signature locks scope as the customer agreed to it, so changing the scope means a new variant and a new signature.

Delete a variant

You can delete a variant when both of these hold:

• There's at least one other variant on the offer (every offer keeps at least one variant).
• The variant isn't attached to an active (non-withdrawn) signature request. To delete one that is, withdraw the signature first or wait for it to expire.

The variants overlay's three-dot menu surfaces the delete affordance.

Note: Variant deletion has no undo. Confirm before deleting.

Set up full feed-in (Volleinspeisung / Full Revente)

Model full feed-in on the variant itself. Set the Feed-in tariff field on Planning > Solar > Solar parameters to your negotiated full-feed-in rate, then reduce the customer's self-consumption to near-zero on the consumption profile so all PV production routes to the grid. The economics page then reflects feed-in revenue as the sole revenue stream. Enter your contracted value as the rate.

This is the same approach across markets, including the French Full Revente. Verify the feed-in tariff value on the variant matches the customer's contracted rate.

Things to know

• Variants are numbered per-offer. The first variant is variant 1, the second is variant 2, and so on. The number appears on the PDF as the variant number, formatted by your offer's option-number template (default: just the variant number, e.g. 2). The name is yours; the number is assigned automatically.
• The default planning mode for a new variant comes from your workspace's preferred mode. If your workspace defaults to "Plan3D Standard", new variants open in Standard; set "Streamlined" and that becomes the default. Override per-variant when needed.
• The "duplicate for installation" shortcut. When you transition a signed offer to installation and the offer has multiple variants, you can duplicate the signed variant into an "Installation: \<name\>" variant, ready for installer edits.
• Variant ordering on the PDF follows the overlay. Variants render in the order they sit in the variants overlay. Reorder via the overlay (drag) to set the recommendation order on the customer's PDF.
• Variant snapshots are frozen at signature. When a customer signs, the bill of materials, prices, 3D plan, and financing terms are captured exactly as they were. Later edits to the offer's other variants, your component prices, or the catalog leave the signed snapshot unchanged.
• The customer-portal view depends on your configuration. If your customer portal is set up for the multi-variant flow, the customer compares the included variants side by side and signs in the portal. Otherwise they see the offer PDF and sign via the standard flow.
• Consumption data is shared across variants on residential offers. The consumption profile is one set per offer that every variant shares. When two scenarios genuinely need different consumption, the cleanest path is two separate offers. Commercial projects support CSV load-curve uploads at the offer level.
• A variant won't delete in two cases: it's the only variant left on the offer, or it's attached to a non-withdrawn signature request. Withdraw the signature in the second case.
• Copy a package to a different offer via a planning template. Variants are tied to one offer. To reuse the same package on a new offer, save the configuration as a planning template and apply it to the new offer's variant.
• The simulation runs per-variant when you save. Three variants on an offer means three independent simulation runs as you save each one. Heavy planning sessions can take a few seconds per variant.

Need help?

• Step-by-step questions about this flow → contact your Reonic account manager.
• Bug reports → include a screenshot and the URL where it happened in your support email.

Last updated on August 4, 2026