Billing and Usage

Mandaitor’s approved first-tranche commercial direction is one B2B, metered-only offer. The offer is identified as mandaitor, charges EUR 0.10 per 1,000 billable units, and has no base fee and no included allowance. This page describes the intended public billing behaviour. It does not amend a customer agreement, and the legal, tax, and final unit-acceptance launch gates remain open as described below.

Commercial model and billing boundary

Item	Direction
Offer	One B2B, metered-only Mandaitor offer.
Product identifier	mandaitor
Price	EUR 0.10 per 1,000 billable units.
Base fee	None.
Included allowance	None.
Billing period	Calendar month in the Europe/Berlin time zone.
Environments	dev, test, and prod are separate billing boundaries.
Customer relationship	One Stripe Customer per product owner, separately in each environment.

A product owner is the B2B party responsible for the Mandaitor product relationship. Its Stripe Customer, subscriptions, local billing projection, and usage ledger must not be shared with another product owner. Likewise, customer or subscription records from dev, test, and prod must never be reused across stages.

Payment collection does not activate paid service

Mandaitor may collect a payment method through a Stripe SetupIntent. A successful SetupIntent or payment-method collection confirms only that payment-method collection succeeded. It never activates paid service.

Paid service becomes active only when the local billing projection records both of the following conditions:

1. An eligible subscription that is owned by the applicable product owner for mandaitor in the applicable stage.
2. An initial invoice that is paid, or that is legitimately zero.

Stripe lifecycle information is projected into a durable local billing state rather than being inferred from a browser response or treated as a live Stripe lookup. The local projection is the state that service-entitlement checks use. A collected payment method, a customer record, or a subscription that does not meet both activation conditions is not sufficient for paid activation.

Provisioning is explicit and scoped to the owner and stage. There is no public plan catalogue to select from and no automatic platform-wide customer or subscription synchronisation.

Transparent usage-unit proposal

Mandaitor records meterable work in a local, durable usage ledger. This ledger is authoritative for usage quantities, corrections, aggregation, and the billing-period total. Stripe is not the authoritative usage ledger.

The following technical weights are the proposed transparent unit contract. A meterable action is assigned once to its applicable row; the combined verification rows are totals for that verification outcome and are not added again to the base verification row.

Meterable action	Billable units
verify	1
verify + PoM	2
verify + drift	1.5
Mandate creation	5
Mandate lifecycle operation	2
Read operation	0

The ledger preserves the stated weights, including fractional units. It must not round a request, an hourly aggregate, or a daily aggregate to a 1,000-unit block.

Aggregation, reconciliation, and invoicing

Usage is aggregated hourly for operational reporting. A daily reconciliation checks the hourly results against the durable ledger and corrects reporting or billing inputs when necessary. The usage dashboard is designed to show recorded usage with a target delay of no more than two hours; this is a reporting-freshness target, not a real-time guarantee.

At the end of a Europe/Berlin monthly billing period, Mandaitor totals the complete monthly ledger aggregate and rounds that aggregate only up to 1,000-unit blocks:

invoice blocks = ceil(monthly aggregate units / 1,000)
charge in EUR = invoice blocks × 0.10

For example, 1 unit and 1,000 units each result in one 1,000-unit block, while 1,001 units result in two blocks. A period with zero usage produces no invoice.

Mandaitor accepts verified late corrections for up to seven days after period close. A correction after close is handled as a billing credit adjustment. It must not be represented by negative usage in a later period or by rewriting the closed period’s consumption history.

Spend visibility without a hard cap

A product owner may set a monthly EUR budget for visibility. Mandaitor sends spend alerts when the accrued usage charge reaches 50%, 80%, and 100% of that owner-set budget, subject to the dashboard’s reporting delay. The budget is an alerting threshold only: it does not create a hard cap, included allowance, automatic suspension, or usage throttle.

Launch-gate reviews still required

The commercial direction above is approved, but two decisions are deliberately not presented as complete:

• Legal and tax wording: Customer terms, invoice wording, VAT or other tax treatment, and any jurisdiction-specific requirements require legal and tax review before charging begins.
• Final unit acceptance: Product, commercial, finance, and engineering review must confirm that the proposed unit categories and weights accurately describe the billable technical behaviour before launch.

Until those launch gates close, the unit table is a transparent proposal for the mandaitor offer rather than a final legal billing commitment.