AYXZA · SCORE Product overview IT · EN
Installed product Single-tenant · no shared data Margin analysis and scoring

The real margin on every customer, every item, every supplier.

AYXZA Score rebuilds a reseller's profit and loss at the granularity of the single contract line: revenue, unit purchase costs, shares of flat-fee costs distributed by declared driver, support load, the financial cost of working capital, charges arising from unpaid invoices. On top of those figures it builds named scores, always decomposable into their own components. Installed on the reseller's own premises.

↓ The problem · § 01
ITEM CUSTOMER PERIOD ONE CELL
The cell is the unit of the system · contract × customer × item × period
01
The problem
Turnover ≠ margin

A reseller knows turnover per customer. Almost never the margin.

Flat-fee contracts covering a set of licences, other items sold at a discount, support bundled into the subscription, on-site and remote installations, third-party products, collection terms that differ for every customer. The real cost of serving a customer is scattered across supplier contracts, tickets, ageing reports and unpaid invoices: it exists, but it is nowhere in particular.

The consequence is that the decisions that matter — renewal, price increase, termination, renegotiation with a supplier — are taken on turnover, the only figure available per customer. AYXZA Score brings every component onto a single calculation base and keeps them distinguishable all the way to the last view.

TODAY · THE COST OF SERVING A CUSTOMER IS SCATTERED supplier contracts flat-fee components tickets and call-outs ageing and collections unpaid invoices CALCULATION BASE one only, per period finest granularity never lost WHAT BECOMES DECIDABLE What I margin on each customer and each item What a supplier relationship really costs Which customers are a problem risk · load · profitability
Fig. 01 · The three questions the product answers in a defensible wayDiagram
A neutral product
The originating case is a business-software reseller with mixed flat-fee and discount contracts. It is the validation case, not the scope: no concept specific to that case exists inside the system, everything emerges from the way the catalogue is configured.
What it does not do
No invoicing, no bookkeeping, no document management: the system reads, it does not issue. No ticket workflow: support enters as a measure of load already incurred. No central archive across installations.
02
The cell
Contract × customer × item × period

One single set of cells. Every view is a sum over that set: two views cannot disagree.

Every amount the calculation produces lands on a cell identified by contract, customer, item and period: the finest granularity is never degraded. The result table is narrow — one row per amount, with the three axes of nature carried as data on the row. Quantities live in a companion structure, each with its own unit of measure, and are never added to amounts.

CELL CONTENTS · SEVEN COMPONENTS OF A CLOSED REGISTER direct revenueLINE PRICE allocated revenueSHARE OF LUMP-SUM PRICE direct supplier costLIST − DISCOUNT allocated flat-fee costSHARE OF POOL allocated support costSHARE OF LOAD financial costEXPOSURE × RATE unpaid-invoice chargeFEES AND LOSSES QUANTITY · COMPANION STRUCTURE, WITH UNIT OF MEASURE EVERY FIGURE DECLARES ITS OWN NATURE ORIGIN direct · attribution without conventions allocated · share of a total, driver declared SOURCE actual · measured on the data conventional · from a rule or standard cost PARAMETER PROVENANCE computed · derived · manual applies in scores: no figure that cannot be broken down
Fig. 02 · The component register is closed: it extends by decision, never by conventionDiagram
1
set of cells
every view is an aggregation: by contract, customer, item, family, supplier, group, period
3
axes of nature
component, origin, source: row data, not separate columns
7
components
a closed register, extended only by a declared decision
0
rounding lost
every distribution happens in whole cents, by construction
03
From revenue to margin
One period · illustrative figures

Margin is not a number: it is a descent whose every step is visible.

The same breakdown holds for the total, for a single customer, for a single item. The hatched components are allocated: they come from a total distributed by a declared driver, and they stay recognisable in every view. The financial cost remains a separate component, never merged into the operating margin.

25,00020,000 15,00010,000 5,0000 27,670 −14,590 −4,250 −2,740 −265 −310 5,515 REVENUEDIRECT + ALLOCATED SUPPLIER COSTDIRECT FLAT FEEALLOCATED SUPPORTALLOCATED FINANCIALCOST UNPAIDINVOICE CHARGE MARGIN 19.9 % REVENUE DIRECT COST ALLOCATED COST · DECLARED CONVENTION MARGIN
Fig. 03 · One period, three customers. Illustrative figures, not real dataChart · euro
Direct and allocated
The sum of per-customer margins always equals the reseller's overall margin. What differs between customers is how much of their cost is conventional: a readable figure, not a footnote.
Cost composition
In this period: 15,165 of direct cost against 6,990 of allocated cost. The ratio is itself an indicator: it says how much of the judgement rests on a convention.
Simulations
A scenario is a layer of hypothetical changes — a price adjustment, a termination, a new contract — applied over the real data and recalculated by the very same engine. There is no second engine for hypotheses.
04
Flat fees, drivers, reconciliation
Distribution down to the item

A flat fee is a cost without a customer. Allocation gives it one without hiding the convention.

A supplier contract carries two natures of cost. Unit-priced items have a cost per unit (list minus discount) and reach the cell by multiplication: no convention involved. Flat-fee components are a single amount referring to a set of covered items: they reach the cell by distribution, following a driver declared for each component, and down to the level of the individual item, not merely the customer.

SUPPLIER CONTRACT unit-priced items list − discount, per unit flat-fee components single amount, no customer DIRECT PATH unit cost × line quantity DISTRIBUTION DRIVER covered units · weighted units revenue generated · fixed share manual percentages ALLOCATED PATH CELL · CONTRACT × CUSTOMER × ITEM × PERIOD revenue − direct costsUNIT-PRICED − allocated costsCONVENTIONAL = margin, always decomposed STRUCTURAL CONSTRAINT Σ shares = distributed total, by construction largest remainder method, in whole cents
Fig. 04 · Two paths, one cell. Comparing alternative drivers on the same data is a function of the systemDiagram
Reconciliation is not a check: it is the method

Every distribution across several destinations happens in whole cents using the largest remainder method: integer shares first, the remainder handed to the decreasing fractions, ties broken by lexicographic order of the cell key. The sum of the shares equals the total by construction, not by after-the-fact verification. The same policy governs the pro-rating of partial validity: a line that changes version halfway through a period produces neither double counting nor lost cents.

TOTAL TO DISTRIBUTE · € 100.00 · DRIVER 7 / 5 / 3 EXACT SHARE cell A · 46.6666… cell B · 33.3333… cell C · 20.0000 NOT REPRESENTABLE IN CENTS INTEGER PART 4666 cents · remainder 0.67 3333 cents · remainder 0.33 2000 cents · remainder 0.00 SUM 9999 · ONE CENT SHORT ASSIGNMENT 4667 centsLARGEST REMAINDER 3333 cents 2000 cents SUM 10000 · EXACT
Fig. 05 · The cent is neither lost nor duplicated: it has a rule, and the rule is deterministicDiagram
Support
Same mechanics. The event carries customer, period, intervention type, a mandatory count and optional hours: with hours the hourly cost applies and the figure is actual, without hours the standard cost of the type applies and the figure is conventional. Attribution to items uses a configurable driver, revenue by default, and happens within the single customer.
Lump-sum pricing
Revenue is allocated exactly as cost is. Where a contract is priced as a lump sum, lines with a known price are locked and the residual is distributed. Locked prices exceeding the agreed total are an error reported, never absorbed.
The engine reports
A flat-fee component with no cells in the covered perimeter, a share that would come out negative, an off-catalogue line left incomplete: the engine raises no exceptions and corrects nothing silently. It reports, and the report stays beside the period's figures.
05
The calculation chain
Pure · deterministic

Same input, same result. Byte for byte, footprints included.

The engine receives the source data and an optional layer of hypothetical changes, and returns a set of cells. It does not write: persistence is the caller's decision, and happens as an atomic rewrite of the period. No dependency on the clock, on read order, or on any external state.

0 HYPOTHETICAL CHANGES ON A COPY The scenario applies to a copy of the source data. From here on the calculation is identical to the real one. 1 SELECTION AND FOOTPRINTS Versions valid in the period on both sides, events and unpaid invoices of the period. From what the calculation sees, seven footprints are emitted. 2 DIRECT CELLS Revenue and unit costs, pro-rated for partial validity according to the criterion declared on the item. 3 DISTRIBUTIONS Residual of lump-sum contracts, flat-fee components, support load: driver total over the perimeter, then a share on each cell. 4 ADDITIONAL COMPONENTS Financial cost from theoretical exposure (invoicing cadence, payment terms, configured rate) and charges from unpaid invoices.
Fig. 06 · Sequence per period. Persistence and reading belong to other actors: the engine stops at the outcomeDiagram
Why seven signatures
A single signature would only say "something changed". Seven say what: the check names the diverging family, and the decision to recalculate stays with the reader.
Outside the footprint
The precedence policy governs data intake, not the calculation: it does not enter the footprint. What did get in, on the other hand, is already inside the families.
Input footprints · seven families

Every calculated period keeps, alongside its cells, the calculation date and one signature per family of data the calculation saw. The selected rows are serialised in canonical form and hashed: the footprint describes what the calculation saw, by construction, not a parallel snapshot that might diverge from it. When an input changes, the periods that depend on it are reported as out of date: still readable, declared as such.

FamilyContent taken into account
partiesCustomers, suppliers and payment terms on each side: the input of the financial cost
catalogueCoverages, default list prices, driver weights, pro-rating criteria
contractsVersions valid in the period on both sides, with prices, quantities and pricing mode
supportEvents of the period and intervention types with their standard costs
unpaid invoicesPositions referring to the period, with status and associated fees
configurationDrivers, financial rate, hourly costs, calculation parameters
active functionsWhich components were switched on at the time of calculation
Versions, not overwrites Contracts and price lists live as versions with validity dates. Recalculating a past period selects the version valid at that time and returns the result of that time. The record's creation date, alongside its validity, distinguishes a retroactive correction from a calculation defect.
06
The views
Aggregations of one set

No view computes anything of its own. It sums, and declares what it sums.

REVENUE COMPOSITION PER CUSTOMER · ONE PERIOD Rossi S.r.l. 30.1 % Bianchi S.p.A. 3.5 % Verdi & C. 23.2 % DIRECT COST ALLOCATED COST MARGIN BAR WIDTH = REVENUE OF THE PERIOD Bianchi invoices more than Verdi and margins five times less: the difference sits in the support load, which is allocated cost, and in an unpaid-invoice charge that turnover does not show.
Fig. 07 · Illustrative figuresChart · euro
Permitted aggregations
By contract, by customer, by item, by family or tag, by supplier through coverage, by group of parties, by period, and every combination. Margin per contract — the view a renewal needs — is one of these, not a separate function.
Your own dimensions
Classifications of customers and suppliers are defined by the user: sector, area, channel, whatever is needed. The product does not impose a taxonomy, it receives one.
The customer base on two axes
40 %30 % 20 %10 % 0 % 0102030 SUPPORT HOURS IN THE PERIOD MARGIN % HIGH LOAD · LOW MARGIN ROSSI30.1 % · 8 HOURS VERDI23.2 % · 5 HOURS BIANCHI3.5 % · 24 HOURS
Fig. 08 · The system imposes no thresholds: the quadrants are declared by whoever reads. Illustrative figuresChart
07
Scoring
Named · explainable

A score that cannot be broken down is not a measure: it is an opinion.

Scoring is not pre-packaged. It is built: choose the subject (customer or supplier), choose the parameters, declare for each a normalisation rule on a 0–100 scale — minimum and maximum, percentiles across the base, bands — and a weight. Named scores coexist: profitability, risk, load, or any other question the reseller wants to ask in a repeatable way.

Every parameter declares its own provenance: computed by the engine, derived from a free formula over other parameters, manual for subjective assessments. From the overall score one always descends to each component's contribution, down to the raw parameter value and the cell that produced it.

SCORE "PROFITABILITY" · ON CUSTOMERS · WEIGHTED SUM 0–100 COMPONENT NORMALISED 0–100 WEIGHT CONTRIBUTION margin percentage COMPUTED · PERCENTILES ACROSS THE BASE 12 40 4.8 unpaid-invoice incidence COMPUTED · MIN-MAX INVERTED 30 20 6.0 support hours per thousand euro DERIVED · BANDS 18 25 4.5 average collection delay COMPUTED · MIN-MAX INVERTED 40 15 6.0 BIANCHI S.P.A. 100 21.3 FOR COMPARISON · ROSSI S.R.L. 86.5 ON THE SAME DEFINITION
Fig. 09 · The score is the total of the right-hand column. Illustrative figuresChart
Absolute or relative scale
Each component declares its own scale. Absolute ones are invalidated only for the party that changed; relative ones, based on percentiles, invalidate the period's scores for everyone: if the base changes, everyone's position changes. The overall score inherits the weakest nature among its components, and keeps the normalisation references it used.
Derived parameters
A free formula over other parameters, defined once and reusable across scores: hours per thousand euro of turnover, margin per covered seat, unpaid invoices against the base. They are parameters in full, with declared provenance.
Switchable functions
Not every reseller holds the same data. Some components can be switched off in configuration: switching off excludes from the calculation, keeps the data already entered, removes the parameters from the builder and enters the footprint. It is blocked while scores depend on it.
08
Data intake
Files · manual · connectors

Any business system can feed the product. No business system is inside the product.

Every intake channel is a declared entity, with its own layout and its own policy. Connectors are external adapters: they translate and push towards the same receiving endpoint the file import uses, and therefore pass through the same validation. A badly written adapter cannot corrupt the calculation.

business system · CSV ticketing system accounting API adapter direct entry DECLARED SOURCES FILE LAYOUT column-by-column mapping closed types and conversions no imposed format IDENTITY MATCHES (source, external code) → internal entity without a match the row is held back and waits PRECEDENCE filling is not overwriting manual value protected per field every field remembers which source wrote it SOURCE DATA · ONE INTERNAL TRUTH DETERMINISTIC RE-IMPORT · EVERY ROW HAS A HISTORY THAT CAN BE CONSULTED
Fig. 10 · The receiving endpoint is single: imports and connectors go through the same validationDiagram
Named configuration The whole configuration — catalogue, drivers, calculation parameters, source definitions, standard file layouts — is a named snapshot carrying a version and a date. It is prepared before installation, loaded at first start, exported again after an adjustment. Only one is active: comparing configurations is done with scenarios, never by letting parallel worlds coexist over the same periods.
09
Checks
In service, not in testing

Reconciliations are not a test campaign that ends. They are a page of the product.

Some differences must be nil by construction: if they are not, there is a defect. Others are measures to be observed, not errors: the system shows them and imposes no thresholds. The distinction is declared on every row, because a dashboard that alarms about everything stops being read.

CheckExpected natureWhat it says
Sum of sharesnil differenceAllocated shares equal the distributed total. A structural constraint of the rounding method.
Lump-sum revenuenil differenceThe sum of a lump-sum contract's lines equals the agreed total.
Independent recomputationnil differenceA second path, not going through the engine, rebuilds the same totals from the source data.
Out-of-date periodsmeasurePeriods whose footprint no longer matches the source data. They stay readable, declared as such.
Footprint comparisonactionRecalculation in memory and comparison family by family. It writes nothing: it names the family that changed.
Protected valuesmeasureValues with manual protection active and divergences detected in recent loads, field by field.
Recorded overwritesmeasureHow many times a load replaced a value entered by hand. It is the measure of how apt the policy is.
Unresolved matchesqueueExternal codes without an entity: the reason some rows are waiting, resolvable without repeating the load.
Period reportsqueueWhat the engine reported while calculating, readable beside the figures it produced.
10
Foundations
Single installation
1
instance per reseller
the data never leaves the building
2
databases, one codebase
PostgreSQL or SQLite, schema within the common subset
3
user roles
administration, analysis, read-only · audit trail from day one
0
shared data
no central archive, no benchmarking across installations
LayerChoice
CALCULATIONA pure, isolated package: no database access, no dependency on the environment. Amounts in whole cents, rates in exact decimals, never floating point.
DATAExplicit SQL, no object-relational mapper: the schema is the single source, and the period is written atomically.
APPLICATIONPython · FastAPI · server-rendered pages, with no network dependency at runtime.
DISTRIBUTIONA single container, no external services. A turnkey desktop installation as the final milestone.
OUTPUTRead access to the cube and to scores already calculated, with calculation date and status: the system exposes frozen figures, it does not compute on external request.
No AI component
A declared choice. A margin that depends on a statistical model is not defensible in front of a supplier in renegotiation. Heuristic recognition of file headers stays an accelerator, never a strategy.
Verifiable determinism
The calculation package is verified against an independent oracle, built separately and not derived from the code. Where engine and oracle diverge, the divergence is declared, not absorbed.

"A figure that does not declare its own nature is not data: it is an opinion, typeset."

AYXZA Score · design principle
Origindirect or allocated, on revenue and on cost alike
Sourceactual or conventional, declared on the cell
Provenancecomputed, derived or manual, within the scores
Consequenceevery score breaks down to the cell that produced it