Refund Process Accounting and Operation [Discussion]

[osos96]

Hi Team,

I hope everything is well and good. I would like to initiate a discussion on the topic of the “Refund Process” within SambaPOS. Please accept my apologies if the chosen topic tag is not entirely accurate.

In reference to the following discussions on the SambaPOS forum:

• Refund System 2.0
• Refund Item Button Order Tags
• Refund Item Button

I have observed that @Jesse has implemented an accounting system that issues new “Refund” tickets to customers, effectively reflecting these refunds in the “Refund” account with no interaction with the source ticket. Also, QMcKay nullifying the original sale ticket through price manipulation. While these approaches may have there merits, it is essential to consider the intricacies of accounting and data auditing as well as over refunding auditing when handling refunds.

From an accounting perspective, a refund process should adhere to certain guidelines:

1. A refund must reference its source sale ticket or invoice.
2. The refund amount must be equal to the price of the source sale ticket or invoice.
3. Refunds should not retroactively impact prior financial statements or closed records.
4. Liabilities and expenses should consistently align within the same financial reporting cycle.
5. Affected source sale tickets or invoices must be appropriately tagged to reference the refund ticket.

Specifically, the source ticket must bear a distinct stamp that references the refunded ticket. For example:

x1 Item Name            Refunded - RF05688 ---> {Refunded Ticket No}                     $6.99

From an accounting perspective, the $6.99 refund amount represents revenue received at the time of sale. This financial transaction can be traced through its history, illustrating how this revenue contributed to various financial activities, such as inventory purchases and potential returns, including factors like VAT (Value Added Tax).

Therefore, eliminating this transaction entirely (by reverting it to zero, altering the price or quantity) constitutes an incorrect financial practice. Instead, a valid approach is to link the refunded item with its corresponding “refund ticket.”

In this process, a new refund ticket is generated, timestamped with the date and time of the refund, and reflects a total refund amount of -$6.99, even if the item’s price has subsequently changed (either higher or lower).This affects the current drawer revenue. This refund ticket should reference the source sale ticket or invoice number and should possess a unique identifier with a designated prefix, such as “RF05688.”

For example:

-------REFUND--------
------RF05688---------
 x1 Item Name            Ticket- S846841 ---> {Source Ticket No}                     -$6.99

I believe this discussion will further our understanding of the operational and financial side of SambaPOS and will contribute to it’s development.

Thank you, and I look forward to your valuable insights and contributions to this discussion.

Stay Safe!

[Bob_be]

I agree with you, that the original ticket should not adjusted.

I’m working on a refund tutorial that does just about everything you are mentioning. (I am about 95% complete with the tutorial. I think it takes me just as long to type up a tutorial as it does develop a system.) The only difference is, that it does not use a refund ticket number, just a Refund Ticket type using Ticket Numbering. If the refund ticket is greater than $0.00, the refund ticket will be converted over to a regular ticket-in the event the customer purchases items along with the refund items.

Here is an old animation of the first concept. It is basically the same flow.

I will PM you the files for you too look at.

[Bob_be]

One other thing. There is no Refund Account(s), the Refund system is using Samba’s own accounting system to reverse that transaction(s) (Debits become Credits and Credits become Debits).

I’m not an accountant, nor am I sure that is the proper way to go about a refund.

Look over the files I sent over and let me know your thoughts.

[Bob_be]

@osos96

This refund ticket should reference the source sale ticket or invoice number and should possess a unique identifier with a designated prefix, such as “RF05688.”

Is there a specific reason to have a Refund Ticket numbering for refund tickets? Verses using existing ticket numbers?

[osos96]

Hi Bob, Perfect representation of the concept really well done, as for the ticket numbering actually there are several reasons for this, listing a few of them:-

1 - Tracking and Reporting : Unique numbering helps in tracking and reporting on refund transactions separately. This can be important for accounting, auditing, and financial analysis purposes. It allows for easy identification of all refund-related transactions.

2 - Error Prevention : A different numbering system reduces the likelihood of errors, such as processing a refund as a new ticket or vice versa. This can help avoid confusion and improve accuracy in financial records.

3 - Performance Metrics : If you want to track the performance of your customer service or refund handling team separately from regular ticketing, using a unique numbering system for refund tickets can facilitate this analysis.

4 - Data Analysis : Separating refund ticket data from regular ticket data allows for better data analysis. You can gain insights into refund trends, reasons for refunds, and other valuable information that can be used to improve your business processes.

5 - Documentation : For record-keeping and documentation purposes, having a separate numbering system makes it easier to organize and retrieve refund-related information when needed.

To summarize this, basically it’s mostly for documentation and financial auditing, a main solid reason is VAT systems in most countries that requires the merchant to clearly document the refunds made to deduct their total from the VAT amount due for instance. or for income taxes for merchant as well, not having a well serialized refunding ticket, it does not get processed as a return, hence you pay both VAT and income tax on an order that you refunded.

Also the kitchen performance of let’s say night shift vs morning shift can be determined by the amounts of flawed orders refunded, hence having a prefix tag for it would make it easily identifiable and measured separate from regular tickets.

[Jesse]

Most of this discussion is in relation to retail. In the food business refunds mean many different things. Often as in most cases there is never a ticket involved. Often people just complain the next day and they don’t keep receipts or information towards that.

In restaurants it’s often just a financial transaction which does not require a ticket at all. It is recorded for reporting purposes of course.

This is very good information though thank you.

[osos96]

@Jesse I totally agree, working in the restaurant industry for 4 years (not as long as you guys )
it rarely happens when a customer comes back with the receipt requesting a refund. and I do understand that when a refund is requested only the manager is allowed to execute that transaction.

Still my point being, not refereeing the original ticket may cause erroneous entry of data.

Maybe he ordered a plate with some modifiers that needs refunding, or saying he had extra cheese when he didn’t.

we can always reach the original ticket by asking the visit time and printing a copy of their ticket to verify.

As you mentioned, for reporting purposes we need to label the order as refunded to avoid counting that item sales for instance when measuring the item sales for instance. Also tracking the most refunded items, without tracking these Items, you can’t accurately report which items are usually refunded.

As a restaurant owner, you need to know which items are most likely to be refunded or has most complains to we could address it with the kitchen, investigating the reasons behind them being returned.