01
Data contract
JSON Schema record
A Draft 2020-12 contract for one statement period: volume, count, fee groups, credits, net fees, effective rate, and average ticket. Unknown fields are rejected.
Explore JSON Schema recordOPEN RESOURCE
The Stratamize Statement Audit Model
One statement becomes one comparable record: gross settled purchase volume, settled transaction count, nine reconciled fee groups, statement credits, effective rate, and average ticket — with no cardholder data anywhere in the contract.
MERCHANT OPERATING LAYER
POS+PAYMENTS+SETUP
Configured around the business that has to run it.
What ships in the release
A data contract, a validator, and the proof they work
Version 1.0.0 packages the schema 1.1.0 record contract with the tooling that enforces it, under a CC BY 4.0 license.
02
Validator
Decimal-safe rule engine
Structural, accounting, and privacy validation with exact Decimal arithmetic. Errors carry rule codes and paths only — submitted values are never echoed.
Explore Decimal-safe rule engine03
Evidence
Synthetic test corpus
Two valid and fourteen deliberately invalid vectors reproduce acceptance and rejection behavior, recorded in a reproducible validation report.
Explore Synthetic test corpus04
Integrity
Fail-closed release gates
Inventory, checksum, identity, provenance, and public-attestation checks must pass before a release is called publishable. Verify downloads against checksums.txt.
Explore Fail-closed release gatesMethod
Normalize one statement in four steps
The model uses gross settled purchase volume and net processing fees for one USD statement period of at most 62 days.
-
01
Record volume and count
Use gross settled purchase volume and its matching settled transaction count — not net deposits, authorization volume, or funding totals.
-
02
Classify every processing charge once
Assign each gross charge to one of nine stable groups: interchange, assessments, processor markup, authorization, monthly, PCI, equipment, chargebacks, or other.
-
03
Reconcile to the cent
Gross processing fees must exactly equal the sum of the fee groups; net fees equal gross fees minus statement credits. The validator enforces both.
-
04
Compute and validate
Effective rate is net fees divided by volume, rounded half up to six decimals; average ticket is volume over count at cent precision. Run the validator to prove the record.
Guardrails
Rules the validator will not bend
The contract is designed so a record can be shared, compared, and audited without exposing anyone.
01
Accounting
Exact-cent reconciliation
Fee groups, credits, net fees, effective rate, and average ticket must agree arithmetically at their published precision — no rounding drift.
02
Privacy
No cardholder data, ever
There are no fields for card numbers, bank accounts, credentials, or identifiers, and free-text notes are scanned for PAN-like, bank, and credential patterns.
03
Semantics
Zero-activity months stay honest
When volume and count are zero, effective rate and average ticket are null — fixed monthly fees still appear instead of fabricating a rate.
STRAIGHT ANSWERS
Statement audit model questions
What does the effective rate actually show?
An all-in normalization of the included statement costs. It supports like-for-like comparison across months or providers on the same basis. It does not isolate provider margin, prove interchange qualification, predict a future bill, or guarantee savings.
Can I use the model in my own software?
Yes. The package is licensed CC BY 4.0 and versioned at stratamize.com/statement-audit/releases/1.0.0. It is a derivative of an upstream CC BY 4.0 model; the NOTICE file in the repository carries the required attribution.
Can an application call it without importing Python?
Yes. The repository ships a loopback HTTP service that wraps the unchanged validator: POST a record to /api/validate on 127.0.0.1:8090 and read back rule codes. Submitted values are never echoed in a response.
How do I verify a download?
Every release file is listed in checksums.txt with its SHA-256, and the GitHub release carries the archive digest in a sha256 sidecar. The publication gate in the repository re-proves inventory, checksums, and identity from scratch.
Should I upload a real merchant statement?
No. The model needs monthly aggregates only. Keep source statements private under the merchant's controls, and never attach one to a public repository or dataset.