> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apostra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Seller reporting receipts

> Check how Apostra received and handled delivery reporting for one buyer media buy.

A reporting receipt is read-only evidence of one delivery report Apostra
received for a buyer media buy. It helps you confirm that a report reached
Apostra, see how it arrived, and understand how Apostra handled it. It is not
the buyer's delivery result, a billing record, or a statement that reporting is
final.

Receipts are available only to an eligible seller relationship for that media
buy when reporting status is enabled for the buyer. This keeps reporting
evidence with the seller that owns the storefront relationship. If the read
cannot return receipts, check that you selected the right buyer and media buy
and that your seller relationship is active.

## What a receipt tells you

Each receipt retains its source receipt ID so you can correlate it with the
report your delivery system sent. It also includes:

* When Apostra received the report and the transport used, such as a webhook,
  bucket, or poll.
* Its acceptance state and, when available, a structured reason with source
  detail.
* The total delivery values that arrived in that report, plus its received
  day-and-package totals when they were supplied.

Those received values are evidence of the specific report. They are not
rewritten to match a later correction.

## Receipt states

* **Accepted** means Apostra accepted the received delivery for processing. An
  accepted receipt can still carry a partial-processing reason, so read the
  reason whenever one is present.
* **Rejected** means Apostra did not accept the received delivery. The reason
  identifies the ingestion or processing problem when Apostra has one.
* **Pending** means Apostra received the report but has not completed an
  acceptance decision. For example, polling may be scheduled or delayed.

An acceptance state answers what happened to that receipt. It does not say
that every required source reported, that coverage is complete, or that the
media buy is final.

## Received values, computed values, and canonical reporting

The receipt's values describe what arrived. The tool also returns **computed
daily totals**: Apostra's current ledger values for the media buy, package, and
reporting day. A later report can correct a computed day, so computed values
can differ from the values on an earlier receipt. Use the receipt to trace the
input; use the current computed values to see the ledger's present view.

Canonical reporting evidence is separate again. Its `canonical` result is a
current media-buy readback, not a guessed link from a receipt to a revision.
When managed delivery is exposed for the buyer, it can identify the latest or
last successful canonical reporting revision. Otherwise, revision identifiers
are withheld.

Finality belongs to a canonical reporting revision, not to a receipt. A
revision can be a provisional snapshot or an official result, and a later
restatement creates a new revision rather than changing the earlier one. Do
not infer finality, billing eligibility, or settlement from a recent callback,
an accepted receipt, or a source's cadence. See [Reliable
Reporting](/v2/guides/reliable-reporting) for the reporting model.

## Read receipts in Apostra

Use the V3 MCP tool `get_seller_reporting_receipts` with the seller media-buy
ID and its buyer customer ID. The tool reads one media buy and opens the shared
**Media Buy Timeline** Glance.

The tool returns the newest five receipts, up to fourteen received daily totals
for each receipt, and up to thirty-one computed daily totals. It marks the
corresponding result as truncated when more evidence exists, so a bounded
response is never mistaken for a complete reporting export.

In the timeline, the **Reporting receipts** section shows each receipt's source
ID, state, received time, transport, reason, and available totals. It displays
three receipt cards at a time and lets you page through the returned receipts.
It also tells you how many received and computed daily totals are present and
whether either bounded list was truncated. The timeline is a way to inspect the
same tool result; it does not convert receipts into canonical revisions.

For how to send reporting in the first place, see [Deliver reporting to
Apostra](/v2/storefront/deliver-reporting).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.