@lssm-tech/lib.billing-spec
Country-neutral BillingOS contracts for quote-to-cash primitives, lifecycle evidence, policy metadata, and agent-facing operation descriptions.
This package is the canonical core contract surface. It intentionally does not contain France-only readiness, PA routing, provider credentials, production submission APIs, persistence adapters, UI, or runtime side effects.
Scope
Use this package to model reusable BillingOS concepts before choosing a country pack or runtime implementation:
- commercial parties, billing accounts, seller/buyer/vendor/customer roles, and fiscal references;
- catalog, price book, offer, quote, order/commitment, invoice, credit-note, payment, reconciliation, and tax-treatment references;
- workflow/event/audit/source metadata for quote-to-cash replay;
- accounting-export, revenue-memory, connector-profile, financial-data-vault, and product-surface projection contracts when they are country-neutral;
- agent operation catalog and safety metadata for read/draft/recommend/approval-only billing actions;
- role-aware quote-to-cash cockpit packets, persona-to-managed-role bindings, action availability, and evidence references for downstream bundle/app seams.
Invoice-issuance contracts (additive)
The following additive operation/event contracts describe the France-ready issuance path. They sit alongside the original eight billing contract keys, which are unchanged:
billing.invoice.issue — issue an invoice from a quote/order, producing the canonical invoice record.billing.invoice.submit — submit an issued invoice to a PDP (Plateforme de Dématérialisation Partenaire) / e-reporting target.billing.invoice.submitted — event emitted once submission is accepted.billing.creditNote.issue — issue a credit note (avoir) derived from a prior invoice.
These contracts stay country-neutral: France legal behavior (TVA, mandatory mentions, gapless numbering, NF203, avoir immutability) lives in @lssm-tech/lib.billing-france, and Factur-X/EN16931 generation plus PDP submission live in @lssm-tech/integration.provider-einvoicing.
Payment-provider evidence
BillingOS keeps provider-neutral payment state while retaining redacted evidence needed for reconciliation. BillingProviderReference can identify the provider object, connected merchant account, webhook event, idempotency key, and evidence references without embedding credentials or provider SDK objects. Connector profiles advertise checkout, payment-method, subscription, invoice, dispute, payout, marketplace, and webhook capabilities explicitly.
Provider network calls remain in integration packages. BillingSpec only models their normalized lifecycle and evidence.
Boundary
BillingOS core remains country-neutral. France e-invoicing/e-reporting readiness lives in @lssm-tech/lib.billing-france; deterministic helper behavior lives in @lssm-tech/lib.billing-runtime; CompanyOS/operator composition belongs in examples or an explicit module surface.
Core contracts may describe high-impact operations, but they must carry authority/autonomy and operator-approval metadata. They must not represent silent authorized execution.
Public entrypoints
@lssm-tech/lib.billing-spec — root barrel@lssm-tech/lib.billing-spec/types — country-neutral BillingOS contract types@lssm-tech/lib.billing-spec/validation — contract validation helpers@lssm-tech/lib.billing-spec/fixtures — safe synthetic quote-to-cash cockpit fixtures@lssm-tech/lib.billing-spec/billing-os — additive versioned catalog, exact-money, usage-truth, correction, and FinanceOS posting-handoff schemas@lssm-tech/lib.billing-spec/docs — owner-module BillingOS semantic-contract DocBlock
BillingOS economic truth lifecycle
The additive billing-os surface models estimate → reservation → execution usage → provider actual → rating → invoice/import correction. Provider payloads and credentials remain outside core; only stable redacted evidence references are accepted. Unknown or stale hard-budget knowledge requires review. Reservations, invoice issuance, payment effects, collection effects, and authorized finance posting handoffs require stable ContractSpec Connect authorization references.
Billing-to-finance integration is reference-only: BillingOS emits a balanced posting handoff, while FinanceOS owns ledger acceptance and returns a receipt. Neither package imports the other.
Production-readiness safety boundaries
- No France-specific fields, readiness schedules, PA claims, or provider routing in core.
- No provider credentials, API keys, network calls, filesystem/database adapters, or production billing processor behavior.
- No production PA submission, e-reporting submission, invoice send, mark-paid, refund, write-off, or VAT/tax-treatment mutation without an explicit approval packet.
- No legal advice, tax advice, PA accreditation claim, or full accounting/general-ledger claim.
See docs/billingos-production-readiness.md and docs/billingos-v0-release-verification.md for prompt coverage, release gates, and remaining non-goals.
Canonical contract suppliers
Billing operation factories and DocBlock metadata consume the existing Core contract declarations. Complete billing spec objects, authority requirements, validation defaults and test assertions are preserved. Usage evidence types consume the complete pure Observability Spec declarations from /evidence-record and /signal-spec. Original derivation, defaults and test assertions remain unchanged. Clean declarations and affected consumers still require qualification before integration.
Service agreements (./service-agreement, additive)
Contracts for a bounded managed workflow sold as fixed setup + subscription + metered usage:
ServiceAgreementSchema — immutable agreement versions binding a workflow edition, installation, selected meter editions (each naming its qualifying receipt class), frozen price editions applied per whole half-open period, budget/exhaustion policy, late-arrival rule and terms. Automatic collection requires qualification evidence.ServiceUsageEventSchema — strict, content-free usage facts across the estimate → reservation → usage → provider actual → invoice correction chain, with full-scope idempotency identity and reasoned exclusions.OnPremUsageBatchSchema — signed, digest-only on-prem usage export.ServicePriceVersionSchema, ServiceUsageRatingSchema,
MeteredServiceUsageSchema and MeteredServiceUsageReceiptSchema — a versioned platform price table whose versions are explicitly unpriced or
priced (ISO currency, integer micros, owner decision ref), and the strict, content-free record of one metered service call with its rating (unpriced
with price_not_set or no_price_version, or priced with the exact amount). There is no default price.ServicePilotAcceptanceRecordSchema and ServiceTerminationRequestSchema.- Operations:
billing.service.usage.record|correct|summary|meter,
billing.service.invoiceDraft.compute, billing.service.budget.reserve,
billing.service.onprem.batch.import, billing.service.agreement.terminate, and approval-gated billing.service.invoice.submit|issue
(execution.approval.required) (serviceAgreementContracts).
The subpath is not re-exported from the root barrel.
