Material flows, transfers and an operating journal that closes

A day’s quantities sit on a slip by the weighbridge, the transfers in emails, and the operating journal is created from both on the evening before the audit. That works as long as nobody asks where a figure comes from — and it fails exactly once.

The contract therefore requires daily closure and weekly sign-off by a signed-in person in the journal role; tapinoma does not sign in its own name. The events carry hash and previousHash: that does not make a gap impossible, but it makes it visible — and that is precisely the purpose.

What this case requires

• Masses that are measured, not estimated. Mass is given with the unit kg or t.
• A material code per movement. Without it a quantity is a number without an object.
• The recipient’s permit. A transfer references a permit snapshot; without it the recipient is not evidenced.
• A person authorised to sign for the week. The sign-off is attributable to a person and not a batch run.

The sequence

The table names the responsible call per stage and what exists afterwards. The reasoning for why a stage cannot be skipped follows below it.

Why each stage is needed

1. Record the movement. POST /compliance/material-movements takes facilityId, movementType, materialCode, mass and unit plus source and destination location and the measurement time measuredAt. Recording happens at the weighbridge, not at reporting time — that is the only difference that decides reliability.
2. Evidence the transfer. POST /compliance/downstream-transfers references the transferred assetRefs, the recipient organisation and facility, their permit snapshot in permitSnapshotId and the transport, and requires at least one entry in masses. The permit snapshot is the point: it records which of the recipient’s entitlements the transfer relied on.
3. Close the day. POST /compliance/journal-periods/{date}/close-daily takes facilityId, timeZone, closedAt and an attestationId. The closure is attributed to the signed-in person and their journal role; they re-confirm their login for it, and tapinoma does not sign in its own name.
4. Sign off the week. POST /compliance/journal-periods/{week}/sign-off-weekly references the week’s daily closures and carries an attestation. The sign-off rests with a person.
5. Pull the audit export. GET /compliance/audit-exports/{case_or_period} emits the events with their hashes — for a case or for a period. That is where a gap shows up, and it shows up to you rather than first to the auditor.

curl -X POST \
  -H 'Cookie: __Host-tapinomahub_session=<SITZUNG>' \
  -H 'X-CSRF-Token: <CSRF_TOKEN>' \
  -H 'X-Compliance-Organisation-Id: <ORGANISATION>' \
  -H 'Idempotency-Key: tagesabschluss-2026-09-12' \
  -H 'Content-Type: application/json' \
  -d '{"facilityId":"<facilityId>","timeZone":"Europe/Berlin","closedAt":"2026-09-12T18:00:00Z","attestationId":"<attestationId>"}' \
  'https://api.tapinomahub.com/compliance/journal-periods/2026-09-12/close-daily'

What you end up with

What remains is a period that withstands an audit, because it is not narrated after the fact: quantities recorded at the weighbridge, transfers evidenced against the recipient’s permit, days closed and weeks signed by a person.

Where to find this in the documentation

The binding field lists, error codes and sample responses live in this surface’s OpenAPI contract at docs.tapinomahub.com (tapinoma-compliance). All use cases arranged by surface and role: overview of the use cases.