Several fee rows refer to the same customer payment

A fee row and a payment row count different things

An itemized fee export describes components of charges. Stripe documents that more than one fee row can relate to the same transaction through incurred_by. It also provides product and feature as separate fields. Repeated originating references can therefore describe separate components, rather than repeated customer payments.

If a spreadsheet joins payment details onto each fee row, the payment amount can appear repeatedly as context. Adding that repeated column multiplies the payment by its number of matched components. This is an effect of the worksheet arrangement, not evidence that the customer paid several times.

Preserve the distinction in your working file: one list for payment records and one for fee components. A summary can show the relationship between them, but its payment total must come from the distinct payment records. A payment with no matched fee row should remain visible as unmatched, rather than disappearing from the payment list.

Establish the originating record before grouping

Read incurred_by on each fee row and match it to the actual provider transaction. Preserve the account context as well as the reference, especially if your files contain more than one account. Do not use a customer name, a similar amount or a nearby timestamp as a substitute for the documented link.

Keep the provider reference distinct from the store's order number. If the originating object is not the payment record used in your payment list, follow the documented relationship in the account records and retain that intermediate reference. Where the link cannot be established, leave the component unassigned. Do not force every fee into a customer-payment group merely because this reconciliation focuses on payments.

For each matched transaction, retain all distinct component rows. Record product and feature separately so a broad product label does not erase the more specific charge description. Multiple components do not by themselves prove that all fees are correct; price and contractual questions still require the actual account terms.

Protect the component detail when calculating totals

Give each fee row a traceable reference. Use a supplied identifier when available; otherwise retain the original export filename and row position as an internal locator. This does not invent a provider fee ID. Preserve the original file so the locator remains meaningful when your working sheet is sorted or filtered.

Check for repeated ingestion of the same source row before calculating component totals. Keep different fee rows that share incurred_by; do not collapse them just because they have the same payment reference. Conversely, importing the same row from overlapping copies of an export does not create another fee. If two distinct provider rows appear to overlap, retain both and flag the question instead of silently deleting one.

Keep amount, tax and currency in separate fields as Stripe's report defines them. Do not add tax again to a figure until its definition establishes whether that calculation is appropriate. Group amounts only within a consistent currency and field definition. Retain the recorded signs for adjustments or credits rather than converting everything into a positive cost.

Calculate the matched payment total from the payment list, and component totals from the distinct fee rows. A component summary by payment, product and feature should remain traceable to those original rows. The payment total is a reference amount, not an additional fee to add to the component total.

Distinguish a complete mapping from a complete cost report

A clean relationship between payments and the fee rows you have does not establish that every fee is present. Stripe says fee data may take up to 96 hours after its balance effect to become available. The report covers most balance-paid fees but excludes charges such as Terminal devices, Capital, Atlas and fees invoiced after use. Keep those scope limits alongside your result.

Also preserve the selected date basis. Fees incurred during a period and fees affecting the balance during that period answer different questions. Match the basis and range before comparing totals, and do not assume those changes explain every remaining difference. An unexplained component stays a question for the provider, with its originating reference and row locator attached through the provider's appropriate channel.

For a Prism processing consultation, describe the report, the grouping problem and the unresolved relationship without sending the export through the public form. Include the website and research-only product types. Confirm any reconciliation assistance, responsibilities, fees and terms before work begins. Email follow-up to an inquiry does not book an appointment, buy a service or submit a processing application.

Payment-to-fee component map

Use the sheet to define the mapping for a real payment and its fee components. Keep exact account references and source files in your controlled reconciliation workbook; use anonymized labels or match results here. Preserve each distinct component while counting the payment once. Unassigned fees and missing fee matches remain visible exceptions.

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.