Retail and nonclinical payment allocation sheet
Trace mixed checkout allocations and the supported export reference.
No signup. Enter reference codes, add records and download a CSV. Entries stay in the browser tab. Filled fields do not establish completion, approval or compliance.
| Invoice reference | Payment identity | Retail allocation | Nonclinical service allocation | Supported export reference | Duplicate or privacy exception | Accounting owner role |
|---|---|---|---|---|---|---|
| Invoice-example-7 | Single-payment-example | 80, illustrative | 320, illustrative | Supported-test-export | Bookkeeper-role |
- Starting records are fictional examples, not merchant evidence.
- Keep private documents and actual contacts in your approved business system. Use internal reference codes here.
- Missing required fields indicate an unresolved record. Filled fields do not prove authorization, completion, compatibility or compliance.
- Export to approved business storage. Browser edits are cleared on reload.
A combined med-spa checkout needs accurate payment allocation without carrying clinical information into every export. Identify the accepted retail and service totals, then trace the collection through the supported payment and accounting records. Keep technical care records in their designated system. Your bookkeeper needs the relevant commercial references and amounts, not a copied treatment narrative attached to a processor report.
Use with this guide
med-spa POS and booking integration scorecard
The med-spa POS and booking integration scorecard identifies dependencies around the accounting handoff.
processor export acceptance checklist
Use the processor export acceptance checklist to review the fields and roles behind the file.
Browse the complete medical spa guides and worksheets.
Map the actual systems and record owners
Identify the booking, retail, payment and accounting systems used in the current account. Record which role owns each handoff and what commercial reference connects them. Do not assume the booking platform’s invoice identifier is the provider’s transaction identifier. A shared customer name is a weak substitute for a stable supported reference and risks matching two unrelated collections.
Ask the administrator responsible for the review what fields are actually included in the export and what fields are needed for the bookkeeping. Review unnecessary service detail with the med spa’s designated privacy people to determine if it is needed for the business purposes outlined here. This worksheet is for review of commercial information only and does not attempt to review health information for compliance with health record requirements or to certify any medical information integration for clinical use. The med-spa POS and booking integration scorecard identifies dependencies around the accounting handoff.
Separate allocations from new collections
Retrieve the accepted invoice and verified provider transaction. Identify retail, service and other reviewed components without counting each allocation as another payment. A deposit and final balance might have separate transaction identities, while one combined checkout might have several invoice lines. Preserve those distinctions in the accounting handoff. Record refunds and credits as separate reviewed events rather than deleting the original collection.
The reconciliation sheet records the invoice reference, payment identity, retail allocation, nonclinical service allocation, supported export reference, duplicate or privacy exception and owner. Use fictional aggregate figures and internal codes. It does not process a payment or connect to an EHR. Filled rows organize the review but do not establish every allocation or exported field is correct.
Test a fictional mixed checkout
Suppose a fictional accepted invoice totals $400, with $80 of retail and $320 of nonclinical service allocation. One verified payment covers $400. The accounting test should preserve the single receipt and two supported allocations. Importing $400 for each category would falsely report $800 collected. The example does not describe an actual treatment, customer or standard med-spa price.
For the safe test of the provider’s supported procedure, check what gets deposited into the designated destination for the accounting records. Make sure the correct stable payment reference number is there and that there is no unnecessary clinical information in the proposed bookkeeping file. A single test does not mean the whole platform is compliant. Note the configuration that was tested, any fields that were not supported, and who the administrator was for this review.
Review corrections without spreading private detail
For a return, exchange or refund, retrieve the relevant accepted commercial decision and original collection. Stripe’s refund documentation explains distinct processing statuses and merchant-balance funding for its supported product. Your actual account needs its own instructions. An accounting credit is not proof the payer received money, and a replacement retail item is not automatically another collected payment.
After the review, give bookkeeping the approved coded references and retain private documents in controlled storage. Recheck the export after a platform or mapping change. The owner needs accurate commercial allocations, one traceable payment history and a limited nonclinical accounting handoff. Avoid promising every booking system separates these records automatically or that a public worksheet replaces qualified privacy and accounting review. Use the processor export acceptance checklist to review the fields and roles behind the file.
Sources for this section: Stripe: refund destinations, funding, statuses and failures
Primary sources
BlueFinch last reviewed these sources on October 4, 2026. Payment rules and state requirements can change.
- FTC: protecting business information, need-to-know access and departing-user controls
- Stripe: refund destinations, funding, statuses and failures
Use this page for general business information. It is not legal, tax, or accounting advice.