Zespy.EzPay.InvoiceEvidence 1.7.1

Portable invoice evidence

Zespy.EzPay.InvoiceEvidence is a .NET 10 library for portable invoice models, canonical JSON and offline invoice verification. Public types use the Zespy.EzPay.InvoiceEvidence namespace. Consumers do not reference ezPay domain, API, storage or issuance implementation.

It supports the existing v1 evidence bundle, v2 managed invoice evidence, v3 managed invoice content and v4 complete invoice evidence profiles. V4 retains commercial party and payment facts, an access-neutral descriptor of the exact original PDF, and frozen due-date/cancellation facts when present. The descriptor grants no access and contains no public share link. CLR namespace changes do not change profile identifiers, JSON properties, canonical bytes, cryptographic algorithms or retained signatures. Product implementation namespaces and assembly forwards are not a supported public compatibility contract.

The invoice verifiers enforce invoice-specific content rules in addition to the portable certification and signature checks supplied by Zespy.Signing.Verification. Generic signing verification alone does not validate the complete invoice business content. Trust policy and accepted roots must come from independent consumer configuration. Never adopt an invoice-provided root, environment or organisation identity as trusted input.

Consumers must match invoice, version, provider and recipient to their authorised product binding. A verified signature does not grant access, establish present permission, certify independently verified legal-business identity, service delivery, NDIS eligibility, claim acceptance, payment or a trusted timestamp. Historical verification and current account authority are separate concerns. Receipts attest the receiving product's admission of exact content; they are not approvals or payment evidence.

Managed certificates distinguish ez.platform-account-attestation.v1 (an automatic platform organisational seal under the product's ordinary action authority) from ez.account-delegation.v1 (the existing explicit-delegation policy). Both retain their exact signed policy and are verified through the shared signing verifier. An automatic seal attests the EZ account workflow and exact content; it does not claim a personal signature or invent human consent. Consumers must retain that distinction when describing the evidence.

The package does not issue certificates, hold keys, call an issuer or sign invoices. Legacy producer signing and root-sealing ports live in private ezPay implementation layers. The optional VC/status-list candidate and its bounded GZIP decoder remain private producer research with their tests; they are not part of this public invoice API or production certificate acceptance.

Participant approval is an additional record. It never replaces the issued invoice, rewrites its original PDF or turns a receiving acknowledgement into an approval. PortableParticipantInvoiceApprovalHistory carries the exact issued invoice/version/source/PDF binding, the original issuer manifest once, and ordered approval statuses. Pending or unavailable statuses are not signed approvals. A retained approved entry carries its own invoice.participant-approved assertion and dedicated EZ service certificate; it does not reuse the provider's invoice.issued delegation.

Consumers independently configure accepted roots and the expected service account scope, verify the original provider proof and exact original PDF digest, and verify each approval against its exact invoice JSON, issued version and original issuer-manifest digest. The platform assertion records the authenticated account action, actor/context, frozen authority revisions and original admission time. It is not a certificate of independently verified personal identity. Frozen admission and authority snapshot digests are issuer audit commitments; the portable record does not disclose the private Claims snapshot or independently prove Claims policy evaluation.

The original document descriptor is a stable identity and content digest, not a download capability. Products resolve it through their authenticated APIs and recheck current access before disclosure. The PDF bytes belong in an authorised download or export archive; they are not embedded repeatedly in approval-history JSON. Later participant approval, claim, payment, receipt or refund evidence must be separate records referring to the exact issued version and relevant preceding action. Those later financial records are not implemented merely by defining this extensible linkage.

The additive PortableTransaction* reference contracts front-load that linkage without adding fields to any existing signed invoice or approval profile. They are contract shapes, not financial event execution or signed financial proof. Use EvidenceJson for strict closed, duplicate-safe JSON and PortableTransactionReferenceRules.Validate for bounded shape and reference consistency. Successful validation authenticates no source, checks no claimant/payee permission and establishes no bank settlement, balance or claim acceptance. Actual future source adapters and purpose-specific verifiers must supply those checks.

Source identity includes namespace, environment, opaque source account and connection/book epoch. Object identity includes kind and opaque ID; revision selects its exact source state. Event ID and source revision are distinct from object revision. The event retains payload digest, qualification, reconciliation status and local observation instant. Source time explicitly distinguishes instant, calendar date and unknown, and resource creation from effective/reported occurrence. Independent clocks do not establish order. A provider-reported receipt remains provider reported after shape validation or a future signature.

The first financial-reference profile is AUD only: nonnegative amounts use exact decimal strings with two fraction digits; actual claim/payment/allocation/receipt/refund amounts are positive, while fees/net may be zero. Quantity is positive with at most six fraction digits, without redundant trailing zeros. Future currencies/precision or FX require a deliberate contract extension; no silent conversion is supported. Funding, supplier money and commercial credit remain separate identities. An allocation may name an exact invoice version without inventing a service line; a named line must match that same version. Legacy lines use explicitly derived version/profile/position references. Claim, immutable attempt and claim-line identities remain distinct and may link many invoice lines. NDIS routes require their scheme and category context; private invoices need neither a fake NDIS claim nor number.

Synthetic acceptance examples (not operating adapters or calculated product balances):

PortableTransactionReferenceTests exercises these shapes, date-only/manual and unknown event time, immutable line identity, source epoch/environment refusal, alternate-revision duplicate allocation refusal, exact AUD amounts and strict JSON. The contracts reserve no funds, prevent no external double claims, execute no payments, and grant no document access. Future financial assertions require their own defined purposes and admission; current invoice.issued / invoice.participant-approved scopes do not cover them.

The product's normal public-package pipeline publishes this SDK and its matching symbols to nuget.org. Its Signing Contracts and Verification dependencies must also be published there before this package is released. Consumers need no Zespy private-feed credentials. The library performs offline verification; access to hosted integration APIs still uses the product's normal subscription and API-key authorisation. Local draft packages may be validated through an explicit task-owned feed, but machine-specific feed paths must not be committed. Packing or passing local tests does not establish feed publication, deployment, issuer readiness or customer activation.