One brand’s application uses the company’s total revenue

Define the company total before extracting a brand total

Copy the application’s requested entity, storefront, period and measure. Company revenue, card-processing volume and the activity of one domain are different descriptions. Preserve the label on the source record: an itemized processor export is not automatically the company’s complete revenue history, and a company-wide figure is not automatically the storefront’s sales.

Stripe’s balance summary report covers a selected period in settlement currency, offers itemized transactions, and separates gross, fee and net amounts. It does not associate payouts with payment transactions. Use it within that scope when the account is Stripe. Record the period, currency and amount basis before comparing it with an order export; the mere availability of itemized rows does not establish which brand generated them.

Require a traceable link for each attributed amount

For each activity entry you want to assign, look for a real link from the payment record to the originating order or invoice and from that record to the selling storefront. A store’s order reference, domain recorded on the order, or another retained identifier can support that link when its meaning is documented. Verify that the reference identifies one record; an order number reused by different stores is insufficient by itself.

A shared customer, similar product description or common bank destination can suggest where to investigate, but cannot independently establish the storefront that made the sale. Where the account history or routing changed, keep the dated mapping that applied to the transaction. Today’s website name does not prove which brand generated earlier activity.

Put a record with no reliable link into an unattributed group. Keep conflicting links there too, with the reason they conflict. Do not distribute this group in proportion to the known sales, allocate it equally among brands, or treat it as belonging to the applying storefront because that storefront is the current focus.

Reconcile the allocation without counting the company twice

Within one defined period, currency and measure, separate the source total into activity attributed to the applying storefront, activity attributed elsewhere, and unresolved activity. These groups should account for the same source set without overlap. If they do not, identify the missing or duplicated record instead of adding a balancing amount. Keep unlike currencies or amount bases in separate reconciliations.

Refunds, fees and other balance entries need their original labels. Do not count every row in an itemized balance export as a new sale. Where a relevant adjustment can be linked to a payment and its storefront, retain that relationship; otherwise keep the adjustment unresolved. Whether the application wants gross payments, an adjusted amount or a different measure is a separate definition to obtain from the requester.

Present the storefront figure as a subset of the shared total, not an additional amount to add to it. Retain the untouched source file and a separate attribution schedule. That lets the reviewer see the company context, the basis for the brand claim and the amount the records cannot allocate.

Explain the evidence boundary in the application

State the legal entity that owns the records, the storefront under review, the covered period, and which identifiers connect the claimed activity to it. Report the unattributed portion explicitly. If no reliable brand split exists, the useful answer is company-level history with an unresolved storefront allocation. It is not a fabricated brand total or a claim that the storefront had no activity.

Stripe’s multiple-account documentation says independent projects, websites or businesses need separate accounts, while the same legal entity can appear across accounts with appropriate public information. A new account does not inherit special status. These account rules explain why a shared tax identity is not a substitute for identifying the business behind each payment; they do not validate your historical allocation or establish eligibility for a research-only catalog.

For a Prism processing consultation, describe which storefront is applying, which records are shared and what portion cannot be attributed. The provider decides what history it will accept and how its application fields should be completed. Prism’s consultation scope, responsibilities, fees and terms are confirmed before work. Keep transaction exports and private entity documents out of the public inquiry.

Brand-level history attribution

Complete this for the actual storefront and requested reporting period. Keep the detailed transaction mapping privately alongside unchanged source files. Use the final column for your finding and a safe internal record label; unknown activity remains visible in the reconciliation.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.