A remittance that nobody can check
Once a month an email arrives from one of the spa break or experience sites you sell through. It has a CSV attachment with voucher numbers and amounts, and a bank payment follows a few days later. Your bookkeeper compares it to the spa's own list of reseller bookings, which is a spreadsheet reception fills in when a guest calls with a reseller code.
Half the codes in the remittance are not in the spreadsheet, because reception validated them in the reseller's portal and forgot to log them. Several guests who came in the month do not appear in the remittance at all. Nobody knows whether they were not validated properly, were paid in a different month, or were never going to be paid.
Three records, no key between them
Each reseller has its own portal, its own code format and its own payment cycle. The spa's booking system records the guest and treatment but not the reseller's reference in a field anyone can report on. Validation in the portal is the step that triggers payment, and it is easy to skip on a busy morning.
- Reseller references are typed into booking notes, if at all.
- Portal validation is done by some receptionists on booking, others on arrival, others never.
- Remittances arrive in different formats from each reseller, net of commission.
- No-shows and late cancellations on reseller vouchers follow the reseller's terms, which differ from yours.
- The price the reseller pays you per package changes when you renegotiate, but old vouchers keep the old rate.
Money you earned but may never see
Unvalidated redemptions can mean a treatment given for nothing. Mismatched remittances take bookkeeper hours every month. Disputes with resellers are hard to win without a record of when each code was validated. And without clean data, you cannot tell which reseller channel is actually worth the commission.
How we build reseller reconciliation
- At booking, reception records the reseller and voucher reference in a structured field in your spa system, or on a short form we add, rather than in notes.
- Where a reseller offers an API or a bulk validation file, validation is done from that record automatically. Where they only have a portal, the day's reseller arrivals appear on a checklist that has to be ticked off.
- Each remittance file is imported and parsed, whatever the reseller's format, and matched line by line to your redemption records.
- Matched lines are marked paid. Unmatched lines go into an exception list: redeemed but unpaid, paid but not redeemed, or paid at an unexpected rate.
- The exceptions list gives the bookkeeper what to raise with each reseller, with dates and references.
- A summary per reseller shows bookings, redemptions and receipts over time, so you can judge each channel on facts.
| Exception | Likely cause | What the list gives you |
|---|---|---|
| Redeemed, not in remittance | Not validated, or next cycle | Code, date and validation status |
| In remittance, not redeemed | Validated early, guest no-show | Booking record and reseller terms |
| Wrong amount | Old rate or commission change | Agreed rate for that voucher date |
Month end with matched remittances
The bookkeeper imports the remittance and sees a short exceptions list instead of a long comparison. Reception has one place to record reseller codes and a checklist on the day. The spa manager can see which resellers bring guests who spend on extras, and which ones just fill quiet Tuesdays at a thin margin.
Does this describe your reseller admin?
- Reseller remittances are checked by eye, or not checked.
- Reseller codes are stored in booking notes or a separate spreadsheet.
- Validation in reseller portals depends on who is working.
- You are not sure every redeemed voucher was paid.
- You cannot compare resellers on anything beyond volume.