Multiverse

English

Deutsch

English

Deutsch

Appearance

Controlling ​

The Controlling view (menu item Controlling, directly below weclapp) answers the question: What do we earn on what? It compares the sales revenue of the billable line items against our purchase prices — per product (weclapp article) and per customer, each split into monthly and annual (all amounts net).

Data basis ​

  • Only customers with invoicing enabled are counted (toggle in the weclapp customer mapping). Disabled customers do not appear.
  • Sales side as in the invoice run: the customer's price override before the customer-specific weclapp price before the standard price; quantity from the override, otherwise from the snapshot; extra articles with their own unit price or the article price. For customers with "One invoice line per article" active, the margin mirrors the merged lines: a flat-rate article counts its fixed price once (costs of every participant keep counting), auto-priced groups are priced at the summed quantity.
  • Purchase side — ALSO line items: For ALSO products, the actual subscription purchase price is the master: ALSO delivers the actual monthly purchase price per subscription including price protection; the snapshot stores it as well, and it is the cost basis of the margin calculation (quantity-weighted when several subscriptions of the same product carry different prices). If ALSO delivers no price for a subscription, the list purchase price from the uploaded ALSO price list applies, resolved via service and billing variant. The weclapp purchase price then only serves for reconciliation — without any ALSO purchase price it applies as described below.
  • Purchase side — all other line items: The purchase prices come from the articles' weclapp supply sources — the supply sources are fetched via their IDs, and per article the primary supply source applies (otherwise the lowest position number). Within a supply source only the currently valid price row counts (price history and pre-created prices are skipped); with tiered prices, the lowest tier. The source used is shown on each product row. For extra articles, a manual purchase price can additionally be maintained per line item (in the extra-article form or edit dialog) — there it overrides the supply-source purchase price, e.g. for flat fees without a weclapp supply source of their own. Mapped positions can carry a manual purchase price per customer as well ("Configure per customer" → position dialog): it beats both the ALSO subscription EK and the weclapp purchase price as the cost basis, and while it is set the price-increase radar skips the position (the margin no longer follows the ALSO price); the ALSO↔weclapp comparison keeps running as data hygiene. The purchase price never appears on an invoice.
  • € pass-throughs (e.g. Azure consumption, manual € portals) are pass-through items: their amount is reported separately and does not flow into the margin.
  • Annual line items invoice only in their respective anchor month — the annual columns state the entire annual volume.

Missing prices ​

If a sales or purchase price is missing, the calculation does not assume 0: the affected row shows "—" instead of a wrong margin, and a notice names the specific line items — per row the customer, the article and whether the purchase or the sales price is missing. That makes it immediately visible where maintenance is needed. You maintain purchase prices in weclapp on the article (supply source → purchase price) — afterwards simply hit "Refresh". ALSO line items normally get their purchase price automatically from the subscription data; as a fallback, uploading the current ALSO price list helps (both take effect from the next ALSO snapshot).

Usage ​

The view is organized into four tabs:

At the top right, "Export CSV" downloads the core tables (products and customers) as a file — see CSV export.

Revenue leakage (delivered but not billed) ​

The "Revenue leakage" card lists snapshot quantities that end up on no invoice — valued as a € amount using the known sales price (an estimate), biggest leak first:

  • Entire customers: mapping present but invoicing disabled — or a snapshot customer entirely without a weclapp mapping. Fix in the customer mapping.
  • Individual line items of enabled customers: switched-off line items, line items without an article mapping (no price, therefore unvalued) and annual line items without an anchor month, which the invoice run otherwise never invoices.

Not every row is an error — deliberately disabled customers/line items simply stay listed. The list only makes visible what remains unbilled and what it costs.

Loss and zero-margin list ​

The "Loss and zero-margin list" card is the sales-side counterpart to the purchase-price deviation list: all line items whose sales price is below or equal to the purchase price (cost basis as in the margin: actual ALSO purchase price before weclapp purchase price) — per customer and article with sales price, purchase price and € effect per period, biggest damage first. Selling below the purchase price is marked red, zero margin subtly.

Purchase-price deviations (ALSO vs. weclapp) ​

As soon as ALSO purchase prices are available, Controlling reconciles them with the purchase prices maintained in weclapp:

  • A "Purchase-price deviations: ALSO vs. weclapp" card in the "Findings" tab lists every deviation as its own row (article, customer, ALSO purchase price, weclapp purchase price, difference), biggest deviation first — the work-through list for weclapp maintenance. Plus the counters for how often the purchase price is identical or no weclapp purchase price is maintained at all.
  • "Apply purchase price" quick fix: Every deviation row has a button that writes the row's ALSO purchase price directly as the weclapp purchase price — after a confirmation showing both values. It writes to the place Controlling reads the purchase price from: the currently valid price row of the best supply source (price history and tiers remain untouched), otherwise the purchase-price field on the article. In weclapp the value applies to the article as a whole — if another customer carries a different price-protected purchase price, that row remains. If the weclapp purchase price has changed since the view was loaded, nothing is overwritten — instead you are asked to refresh; every correction is recorded in the audit log. Afterwards hit "Refresh" — the row disappears from the list.
  • The same findings also appear on the respective product row (deviation yellow, missing weclapp purchase price subtle, match with a green check mark).
  • Since the ALSO purchase price is the actual subscription price including price protection, deviations are genuine maintenance cases — even for price-protected existing subscriptions. However, an article can carry different price-protected purchase prices per customer; a single weclapp purchase price then cannot match them all. The price protection is shown right next to it in the tables.
  • Period basis: The ALSO subscription purchase price is a monthly value. Non-monthly line items — above all prepaid annual subscriptions on the annual invoice — therefore compare on their invoice period: the monthly purchase price is scaled up (annual = ×12) and the row carries the suffix "per year" (or "per quarter"/"per half-year"). This way the ALSO purchase price does not sit next to the weclapp annual purchase price as a phantom deviation. The same basis applies in the margin calculation, the loss list and the price-increase radar.

Price-increase radar ​

Price-protected ALSO subscriptions have a frozen purchase price. When the price protection expires, the purchase price jumps to the current list price — if that is higher, the margin drops. The price-increase radar (card in the "Findings" tab) makes this upcoming burden visible before it hits:

  • One row per customer and article — only where the future list purchase price is above the protected current purchase price (a real increase; cases where the list price has since fallen deliberately do not appear).
  • With the price-protection expiry date (earliest first; expired red, expiring within 60 days yellow), quantity, purchase price now → purchase price then and the extra cost per period (difference × quantity). At the top right, the total per month/year.

This makes it possible to react in time — adjust the sales price, renegotiate or restructure the renewal. The basis is the stored subscription purchase price and the list purchase price of the same snapshot; the radar therefore kicks in as soon as both are available.

Price protection ​

Both tables show ALSO price protection: per product, which customers have price protection, and per customer, which articles — each with the expiry date. Expired price protection is marked red, expiry within 60 days yellow; the column sorts by the earliest expiry, so the most urgent cases are at the top. The data basis is the stored ALSO subscription master data of the latest snapshot; if several subscriptions of the same product hold price protection, the earliest expiry date applies.

Margin history (monthly actuals) ​

The nightly snapshot freezes Controlling as the monthly actual — grand totals as well as the values per article and customer. The current month is updated every night; the last state of a month remains as history. The "Margin history" card at the bottom of the view shows the frozen months with revenue, margin, margin % and pass-through (a * marks months that were frozen with missing prices — their margin is incomplete). "Freeze now" triggers the freeze manually, e.g. right after prices have been maintained.

Important: Nothing is created retroactively — the history grows from activation on. Month comparisons ("margin Q3 vs. Q2") therefore become more meaningful with every month.

Change vs. previous month ​

The "Change vs. previous month" card in the overview compares the current (live) state against the frozen monthly actual of the previous month — switchable per product or per customer, biggest margin movement first:

  • Δ quantity: how many units (seats/licenses) were added or dropped. Since the quantity is a point-in-time value, the card compares today's state with the end of the previous month.
  • Δ margin and Δ revenue (monthly recurring): the € effect of the change — quantity growth and price changes combined. Gains green, declines red.
  • Products or customers without a previous-month row count as new (no quantity delta, but the full margin as a gain).

This too grows with the history: the margin/revenue deltas kick in as soon as a previous month is frozen, the quantity delta as soon as the previous month carries the quantity (from the version that introduces this card).

Concentration risk ​

The "Concentration risk (top customers)" card in the overview shows how much of the revenue depends on a few customers — the higher the share of the biggest customers, the bigger the cluster risk if one of them leaves:

  • The basis is the annual revenue run rate per customer (monthly × 12 + annual); € pass-throughs do not count, because they are not revenue of their own.
  • The KPI chips state the revenue share of the top 1 / top 3 / top 5 customers; conspicuously high shares (top 3/top 5 from 50%) are highlighted in yellow.
  • The table lists the biggest customers with revenue p.a., share, cumulative share and margin p.a. — so it is visible at a glance, for any given customer, how much revenue their loss would cost.

Target/actual per month ​

The "Target/actual per month (Controlling vs. PRE invoice)" card in the overview compares the expected monthly revenue against the invoices actually generated — making visible where the invoice run deviates from Controlling:

  • Target: the expected monthly revenue from the frozen monthly actual (revenue plus € pass-throughs, since the pass-through items are invoiced as well).
  • Actual: the net total of the monthly PRE invoices actually generated for the month — the amounts come live from weclapp, i.e. including manual changes to the drafts.
  • Deviation (actual − target): rounding differences up to €1 count as "OK" (green). Below that, revenue is missing versus the expectation (red); above it, more was invoiced than expected (yellow) — both a reason to take a look.
  • Invoices: how many PRE invoices flow into the month. A * on the actual marks months with invoices whose amount cannot be retrieved (e.g. deleted in weclapp) — the actual is then incomplete.

The comparison needs both: a frozen monthly actual (target) and generated PRE invoices (actual). Only the monthly share counts: on the merged monthly invoice the net of the appended non-monthly positions is recorded at creation and subtracted here — interval positions fire via their anchor month and would distort the monthly picture. (Documents from the earlier one-invoice-per-period scheme count via their billing period as before.)

Invoicing preview / cash flow ​

The "Invoicing preview / cash flow (12 months)" card in the overview shows what will presumably be invoiced over the next twelve months — the basis for rough revenue/liquidity planning:

  • Recurring: the monthly recurring base (revenue + € pass-throughs) as today's run rate, carried forward unchanged into every month.
  • Annual: annual line items fall due in their anchor month — they appear as a spike exactly in the month the annual invoice runs (highlighted). Months without an annual invoice show "—" here.
  • Total: recurring + annual, i.e. the month's expected invoice amount. The KPI chips state the monthly base and the 12-month volume (= annual run rate).

This is not a real forecast but today's state projected into the future: quantity and price changes, cancellations and new customers are not factored in. Annual line items without an anchor month are deliberately absent — they are never invoiced and appear in the revenue leakage instead.

CSV export ​

The "Export CSV" button at the top right downloads the core Controlling tables as a CSV file for further processing in Excel (controlling_YYYY-MM-DD.csv). The file contains two labeled sections:

  • Products: per article the article number, name, purchase price and purchase-price source as well as quantity, revenue, cost and margin (monthly and annual) and the monthly pass-through.
  • Customers: per customer the quantity, revenue, cost and margin (monthly and annual) as well as the monthly pass-through.

The "Margin incomplete" column is marked ja when the line item is missing a sales or purchase price — the reported margin is then too high. The export reflects the currently loaded state (snapshot or live). The file carries a UTF-8 BOM so that Excel recognizes the umlauts correctly.