Regulatory Reporting & DEA Submissions

Regulatory reporting is where a controlled-substance system meets the Drug Enforcement Administration face to face. Every other subsystem — ingestion, classification, storage — exists so that when a report is due, the registrant can produce a document that an inspector will accept without argument. The governing principle of this area is narrow and non-negotiable: a regulatory report must be a deterministic projection of the append-only audit ledger, never a hand-assembled document. When a report is generated by replaying immutable events through a pure function, two people running the generator against the same ledger snapshot get byte-identical output, and any later challenge is answered by re-running the projection rather than defending a spreadsheet nobody can reproduce. This area builds on the Core Architecture & DEA Compliance Frameworks that establish the ledger, and turns that ledger into the periodic and event-driven filings the DEA and FDA require.

The obligations fall into four concrete filings, each with its own statute, cadence, and artifact: Automated Records and Consolidated Orders System (ARCOS) transaction reporting under 21 CFR § 1304.33; theft and loss reporting on DEA Form 106 under 21 CFR § 1301.76; controlled-substance destruction records on DEA Form 41 under 21 CFR Part 1317; and biennial inventory reconstruction under 21 CFR § 1304.11. The remainder of this page maps those statutes to system requirements, presents the report-generator topology with its top-level diagram, links to the specialized references that implement each filing, ships a runnable generator base, and closes with the failure modes an inspection exposes.

Why Reports Must Be Projections, Not Documents

A controlled-substance registrant operates under strict-liability recordkeeping: the DEA does not ask whether you intended an accurate report, only whether the record you filed matches the substances you actually handled. That standard collapses the moment a report is assembled by hand, because a hand-assembled document has no provable relationship to the underlying transactions. An analyst who queries the database, exports to a spreadsheet, adjusts a few rows, and submits has produced an artifact whose lineage cannot be reconstructed. If the report is wrong, there is no way to distinguish an honest transcription error from concealment, and under the CSA both are recordkeeping failures.

The engineering answer is to treat every report as the output of a pure function over immutable inputs:

• 21 CFR § 1304.33 — ARCOS reporting. Manufacturers and distributors must report acquisition and disposition transactions of Schedule I–II (and selected III) substances periodically. Each reported line must trace to a committed ledger event, so the report is a filtered, formatted view of dispositions and acquisitions already recorded.
• 21 CFR § 1301.76 — theft and loss. A significant loss must be reported on DEA Form 106. The report is a projection of the discrepancy between the ledger’s expected balance and a confirmed physical count, not a fresh narrative typed into a form.
• 21 CFR Part 1317 — destruction. Controlled substances rendered non-retrievable must be documented on DEA Form 41. The record is a projection of the waste and destruction events already committed to the ledger, with witness attestations bound in.
• 21 CFR § 1304.11 — biennial inventory. Every registrant must reconstruct an exact on-hand balance for a specific date. That balance is a point-in-time fold over the event stream — the purest projection of all.

When each of these is a projection, the report inherits the ledger’s integrity guarantees for free. The events are append-only and hash-chained, so the inputs cannot be altered without detection; the projection is deterministic, so the output can be regenerated and compared byte for byte. That reproducibility is the property that makes a report defensible: an inspector’s challenge is met not by argument but by re-running the generator in front of them.

System Architecture Overview: The Ledger as the Single Source

Every report described on this page reads from exactly one place: the append-only event ledger defined in Core Architecture & DEA Compliance Frameworks. No generator queries operational tables, mutable projections, or vendor exports. This constraint is what makes reports reproducible — a mutable table can drift between the moment a report was filed and the moment an inspector asks you to regenerate it, but a snapshot of an append-only log cannot.

The topology has three stages. First, a snapshot is taken: the generator captures the ledger up to a sequence number or timestamp and freezes it, so the report is defined against an immutable input even as new events continue to arrive. Second, a generator folds the relevant events into the report’s structure — ARCOS filters to reportable acquisitions and dispositions, Form 106 folds to a theft/loss discrepancy, Form 41 folds to destruction records, and the biennial reconstruction folds the entire history to an on-hand balance. Third, the generator emits a signed, hashed artifact: the report bytes, a SHA-256 digest over those bytes, and a signature over the digest, so the artifact is both tamper-evident and attributable.

Because every stage is deterministic, the whole pipeline is idempotent. Re-running a generator against the same snapshot produces the same bytes and therefore the same hash. That equality is the operational definition of a defensible report: the filing you submitted and the filing you can regenerate are provably the same document.

Core Concept: ARCOS Transaction Reporting

The first periodic obligation is ARCOS. Under 21 CFR § 1304.33, registrants that manufacture or distribute Schedule I–II substances — and specific Schedule III materials — must report their acquisition and disposition transactions to the DEA on a defined cadence, in a fixed-width record format the ARCOS system ingests. The reporting layer must select which ledger events are reportable, map each to the correct ARCOS transaction code, resolve the drug identity to the code ARCOS expects, and assemble byte-exact records. The full treatment of reportable-transaction selection, the record layout, reporting frequency, and batch submission lives in ARCOS Transaction Reporting.

The design tension in ARCOS is between the ledger’s rich internal event model and ARCOS’s rigid fixed-width grammar. Internally an event carries typed fields, UTC timestamps, and normalized identifiers; ARCOS wants specific column positions, zero-padded quantities, and a two-digit transaction code. The generator is the translation boundary, and it must be pure: given the same events it must emit the same file, so that a resubmission or an inspector’s regeneration is bit-identical to the original filing.

Core Concept: Theft and Loss Reporting on DEA Form 106

The second obligation is event-driven rather than periodic. Under 21 CFR § 1301.76, a registrant that discovers a significant theft or loss of controlled substances must notify the DEA and file DEA Form 106. Unlike ARCOS, a Form 106 is triggered by a discrepancy: the ledger’s expected on-hand balance for a substance diverges from a confirmed physical count, and diversion cannot be ruled out. The generator’s job is to project that discrepancy — the substance, the missing quantity, the last reconciled balance, the discovery circumstances — into the Form 106 structure. The reconciliation logic, the significance thresholds, and the automation of the filing from ledger snapshots are covered in DEA Form 106 Theft & Loss Reporting.

Treating Form 106 as a projection matters most here, because a theft/loss filing is adversarial evidence. The registrant is documenting a failure, and the DEA will scrutinize whether the reported loss matches the records. A Form 106 generated deterministically from the audit ledger carries its own provenance: the discrepancy it reports is exactly the difference between two ledger-derived numbers, each of which is independently reconstructable, so the filing cannot be accused of being massaged after the fact.

Core Concept: Biennial Inventory Reconciliation

The third obligation is the biennial inventory. Under 21 CFR § 1304.11, every registrant must take a complete and accurate inventory of all controlled substances on hand at least every two years, and must be able to reconstruct the on-hand balance for that inventory date. In an event-sourced system this is a point-in-time fold: replay every acquisition, dispensing, waste, transfer, and destruction event with a timestamp at or before the inventory instant, and the resulting per-substance balance is the biennial inventory. The reconstruction algorithm, the handling of open lots, and the reconciliation against physical counts are detailed in Biennial Inventory Reconciliation.

The reconstruction depends entirely on the ledger being append-only and complete, which is why the reporting layer inherits — and never relaxes — the audit-log guarantees. Specifically it relies on the audit boundary being drawn so that every controlled-substance mutation is inside it, and on the Merkle-tree audit anchoring that timestamps the log’s integrity, so a reconstructed balance can be shown to derive from events that provably existed before the inventory date rather than being back-dated.

Production Python Implementation

The following is the report-generator base every concrete filing subclasses. It reads an immutable ledger snapshot, folds it through a subclass-defined projection, and emits a signed, hashed report artifact. The base guarantees the three cross-cutting properties — deterministic input via a frozen snapshot, a SHA-256 digest over the emitted bytes, and PHI-free structured logging — so each concrete generator only implements its own projection. It satisfies the reproducibility requirement behind 21 CFR § 1304.33, 21 CFR § 1301.76, 21 CFR Part 1317, and 21 CFR § 1304.11.

from __future__ import annotations

import hashlib
import hmac
import json
import logging
from abc import ABC, abstractmethod
from dataclasses import dataclass, field
from datetime import datetime, timezone
from enum import Enum
from typing import Iterable, Sequence

# Structured logging only — report metadata and hashes, never PHI or patient names.
logger = logging.getLogger("pharmacy.reporting.generator")


class ReportKind(str, Enum):
    ARCOS = "ARCOS"                 # 21 CFR § 1304.33
    FORM_106 = "FORM_106"           # 21 CFR § 1301.76 theft/loss
    FORM_41 = "FORM_41"             # 21 CFR Part 1317 destruction
    BIENNIAL = "BIENNIAL"           # 21 CFR § 1304.11 inventory


@dataclass(frozen=True)
class LedgerEvent:
    """One immutable, already-committed audit-ledger event. Never mutated here."""

    sequence: int
    ndc_11: str
    action: str                    # RECEIVING | DISPENSING | WASTE | DESTRUCTION | TRANSFER
    quantity: float
    occurred_at: datetime          # UTC, tz-aware
    chain_hash: str                # the event's position in the SHA-256 audit chain


@dataclass(frozen=True)
class LedgerSnapshot:
    """A frozen view of the ledger up to `through_sequence`. The report input.

    Freezing the input is what makes a report reproducible: new events may arrive
    after the snapshot, but the projection is defined against these bytes only.
    """

    registrant_dea: str
    through_sequence: int
    taken_at: datetime
    events: Sequence[LedgerEvent]

    def snapshot_digest(self) -> str:
        """SHA-256 over the ordered chain hashes — identifies the exact input set."""
        joined = "|".join(e.chain_hash for e in self.events)
        return hashlib.sha256(joined.encode("utf-8")).hexdigest()


@dataclass(frozen=True)
class ReportArtifact:
    """The signed, hashed output. Regenerating from the same snapshot reproduces it."""

    kind: ReportKind
    body: bytes
    body_sha256: str
    signature: str
    snapshot_digest: str
    generated_at: str
    line_count: int


class ReportGenerator(ABC):
    """Base for every DEA submission. Subclasses implement only the projection."""

    kind: ReportKind

    def __init__(self, signing_key: bytes) -> None:
        # HMAC stands in for an HSM/CSOS signature in this reference implementation.
        self._signing_key = signing_key

    @abstractmethod
    def select(self, snapshot: LedgerSnapshot) -> Iterable[LedgerEvent]:
        """Filter the snapshot to the events this report is responsible for."""

    @abstractmethod
    def render_line(self, event: LedgerEvent) -> str:
        """Deterministically render one selected event to its report line."""

    def _sign(self, body_sha256: str) -> str:
        return hmac.new(self._signing_key, body_sha256.encode("utf-8"), hashlib.sha256).hexdigest()

    def generate(self, snapshot: LedgerSnapshot) -> ReportArtifact:
        """Fold the snapshot into a signed, hashed artifact. Pure and idempotent."""
        # Deterministic ordering: report output must not depend on iteration luck.
        selected = sorted(self.select(snapshot), key=lambda e: e.sequence)
        lines = [self.render_line(e) for e in selected]
        body = ("\n".join(lines) + "\n").encode("utf-8") if lines else b""

        body_sha256 = hashlib.sha256(body).hexdigest()
        signature = self._sign(body_sha256)
        generated_at = datetime.now(timezone.utc).isoformat()

        artifact = ReportArtifact(
            kind=self.kind,
            body=body,
            body_sha256=body_sha256,
            signature=signature,
            snapshot_digest=snapshot.snapshot_digest(),
            generated_at=generated_at,
            line_count=len(lines),
        )
        # PHI-free audit line: kind, counts, and hashes only — never drug/patient detail.
        logger.info(
            "report_generated kind=%s lines=%d body_sha256=%s snapshot_digest=%s",
            artifact.kind.value, artifact.line_count, body_sha256, artifact.snapshot_digest,
        )
        return artifact


class BiennialInventoryReport(ReportGenerator):
    """21 CFR § 1304.11: fold the full history to an on-hand balance per NDC."""

    kind = ReportKind.BIENNIAL
    _SIGN = {"RECEIVING": 1.0, "TRANSFER": 1.0,
             "DISPENSING": -1.0, "WASTE": -1.0, "DESTRUCTION": -1.0}

    def select(self, snapshot: LedgerSnapshot) -> Iterable[LedgerEvent]:
        # Every committed event at or before the snapshot contributes to the balance.
        return snapshot.events

    def render_line(self, event: LedgerEvent) -> str:  # not used; we override generate
        raise NotImplementedError

    def generate(self, snapshot: LedgerSnapshot) -> ReportArtifact:
        balances: dict[str, float] = {}
        for e in sorted(snapshot.events, key=lambda e: e.sequence):
            balances[e.ndc_11] = balances.get(e.ndc_11, 0.0) + self._SIGN[e.action] * e.quantity
        lines = [f"{ndc}\t{bal:.4f}" for ndc, bal in sorted(balances.items())]
        body = ("\n".join(lines) + "\n").encode("utf-8") if lines else b""
        body_sha256 = hashlib.sha256(body).hexdigest()
        artifact = ReportArtifact(
            kind=self.kind, body=body, body_sha256=body_sha256,
            signature=self._sign(body_sha256),
            snapshot_digest=snapshot.snapshot_digest(),
            generated_at=datetime.now(timezone.utc).isoformat(),
            line_count=len(lines),
        )
        logger.info("report_generated kind=%s lines=%d body_sha256=%s",
                    artifact.kind.value, artifact.line_count, body_sha256)
        return artifact


if __name__ == "__main__":
    logging.basicConfig(level=logging.INFO)
    now = datetime.now(timezone.utc)
    events = [
        LedgerEvent(1, "00093-0058-01", "RECEIVING", 500.0, now, "a1" * 32),
        LedgerEvent(2, "00093-0058-01", "DISPENSING", 30.0, now, "b2" * 32),
        LedgerEvent(3, "00093-0058-01", "WASTE", 2.0, now, "c3" * 32),
    ]
    snapshot = LedgerSnapshot(
        registrant_dea="PB1234567", through_sequence=3, taken_at=now, events=events
    )
    report = BiennialInventoryReport(signing_key=b"reference-signing-key").generate(snapshot)
    print(report.body.decode())
    print("body_sha256:", report.body_sha256)
    # Re-running against the same snapshot yields the identical hash — the defensibility property.
    again = BiennialInventoryReport(signing_key=b"reference-signing-key").generate(snapshot)
    assert again.body_sha256 == report.body_sha256

The base class encodes the whole thesis in code: a frozen LedgerSnapshot is the only input, generate sorts deterministically before folding, the output carries a SHA-256 over its own bytes, and the assertion at the bottom proves that regenerating from the same snapshot reproduces the hash. Every concrete filing — ARCOS, Form 106, Form 41 — is a different select and render_line, nothing more.

Compliance Mapping: Statute → Requirement → Artifact

The table binds each governing clause to the requirement it imposes and the concrete artifact this area produces. It is the contract between the compliance reader and the engineering reader.

Failure Modes & Incident Response

Making reports deterministic narrows the failure surface to a small, well-understood set. Each mode has a detection signal and a response that preserves the ledger.

• Non-reproducible report. Regenerating a filed report against its snapshot yields a different body_sha256. This means the generator was not pure — an unsorted iteration, a wall-clock value in the body, or a mutable input leaked in. Detect it with a CI test that generates twice and asserts hash equality; treat a divergence in production as a filing that cannot be defended and regenerate from the pinned snapshot after fixing the non-determinism.
• Snapshot drift. A report was generated against a live table instead of a frozen snapshot, so the input changed mid-fold. Detect it by requiring every generator to record a snapshot_digest and rejecting any run whose digest cannot be reproduced from the ledger. Remediate by re-running against a proper immutable snapshot.
• Unreported significant loss. A physical count reveals a Schedule II discrepancy but no Form 106 was filed within the window 21 CFR § 1301.76 requires. Detect it by reconciling projected balances against physical counts on every cycle and auto-raising a Form 106 draft when the discrepancy crosses the significance threshold; escalate to the compliance officer and the DEA field office.
• ARCOS rejection. A batch is rejected for a malformed fixed-width record or an invalid transaction code. Detect it from the ARCOS acknowledgment; because the file is a projection, correct the mapping and regenerate rather than editing the file by hand, then resubmit the reproducible artifact.
• Retention gap. A filed artifact cannot be retrieved for inspection, breaching 21 CFR § 1304.04. Detect it with a retention-inventory job that verifies every generated body_sha256 is present in WORM storage; a missing artifact is regenerated from its retained snapshot and its absence documented.

Every response path ends at the same invariant: the audit ledger is never edited to make a report come out right. A report that disagrees with reality is evidence of a ledger event that is missing or wrong, and the fix is a new forward-chained correcting event — after which the report, being a projection, corrects itself.

Conclusion

Regulatory reporting under the DEA and FDA is not a document-production problem; it is a projection problem. When ARCOS transaction reporting under 21 CFR § 1304.33, theft/loss reporting under 21 CFR § 1301.76, destruction records under 21 CFR Part 1317, and biennial reconstruction under 21 CFR § 1304.11 are each implemented as a deterministic fold over an append-only, hash-chained ledger, the resulting filings are reproducible, tamper-evident, and defensible. The generator base on this page makes those properties structural: a frozen snapshot in, a signed and hashed artifact out, and a guarantee that re-running produces the same bytes. The specialized references linked throughout implement each filing against exactly this contract, so that when an inspector arrives, the answer to any question about a report is simply to run it again.

Related

• ARCOS Transaction Reporting — periodic acquisition/disposition reporting and the fixed-width record layout
• DEA Form 106 Theft & Loss Reporting — event-driven loss filing projected from ledger discrepancies
• Biennial Inventory Reconciliation — point-in-time on-hand reconstruction under 21 CFR § 1304.11
• Core Architecture & DEA Compliance Frameworks — the event-sourced ledger every report reads from
• Merkle-Tree Audit Anchoring — timestamped integrity proofs for the ledger behind each filing