Payout expenses using a POS ticket

I regularly pay freelance staff based on the activities that they do on a particular day. To handle this I was hoping to use a new ticket type “Payout” with it’s own menu that list the various activities that the freelancer might get paid for. The operator would select these activities and then pay the freelancer from the till when they settle the payout ticket.

I have created the Payout transaction type, but I am unsure of how I should be expect the accounts to be reflected. For me I think I would prefer to see an “Expenses” account rather than just reducing the amount of the sale account. Also, should these Payouts be changing the “Receivables” account, or should I be creating a new account for this purpose?

Also, keep in mind I would like to keep track of which Freelancer I have paid what to. I have freelancers setup as entities with their own accounts. Some times I might over or underpay a freelancer due to a lack of small bills in the till.

Take this example of a potential day with just 1 sale…

  • John does $70 diving and pays just $70 cash.
  • Sofia guides john in the ocean and earns $18 for doing this (I pay her $18 in cash from the till).

What values for the various accounts would it make sense for me to see?

For something like that you probably need to look at having a freelancer entity with a debit/credit account, sorry always struggle on the terminology on which way round it goes.
Then to do this you would ‘ring in’ the job value to the account making it a debit account from your perspective (you owe them which think is right.)
You would then do a payout transaction to reduce that value which is keeping a account for the due/paid values…

Thanks @JTRTech - I am glad I am not the only person who gets all of this credit/debit stuff confused!

One thing I am a little confused about witht he debit vs credit side of things is that it seems I will have to use a ticket payment transaction type which is setup like this:

As you can see, I have the Payment Accounts as the Credit account. I think I have to do this because when chosing a payment type for the ticket this configuration is the only thing that shows the Cash (USD) and Cash (MXN) till accounts that I would be using to make the payment.

But, with the Payout transaction configured in this way, I need the items in the POS menu to be listed as negatives. For example, the price for Ocean guiding would be “-18”. I don’t have any issues with this, I am just checking I am heading in the right direction???


Mate, I cant tell you off top of my head. @Jesse is pretty smooth with accounting movement with any luck he will chip in when online next.
When I was working out cash back I just had to do trial and error and run some dummy transactions to see the movement…

Sale is Sales -> Receivables
Payment is Receivables -> Payment

Think you need input of invoice/iou to account as;
Receivables --> Customer account

And frelancer payment as
Payment --> Receivables

If not doing accounts that would become
Payment --> Expences maybe…

Am just basing that on what the sales and payment transaction do, dont take my word on it…Maybe look at the cashback topic from a while back with paul and myself hashing it out;

1 Like

Thanks - I appreciate it. I will give a read, but @Jesse, if you have any thoughts on this that I would definitly appreciate it :slight_smile:

I personally have never had a satisfactory experience using the POS/Ticket Screen to make Payouts. It simply is not designed for that function. Payouts are really a pure Transaction operation, and even given that, you can set the Transaction Description to reflect what the Payout is for.

When it comes to Vendor, Supplier, or Expense Payouts, the recommended setup does not use the POS/Ticket screen; it uses Account Screens and/or Custom Entity Screens …

The above all use Account Screens and Transaction Documents (Buttons on the Account Screen(s)).

I refined my original Tutorial to use an Entity Screen that has more automation behind it and removed the Buttons from the Accounts Screen… I cannot currently find a Tutorial for this however it is fairly simple setup and it looks something like this:

Since you mention more detailed tracking of what has been paid to whom, it sounds like you might be looking for something more like the Payroll System that I designed. The operation is very similar (nearly identical when it comes to Accounts and Transactions) to Expense Payouts, but in this case, there are some Reports added to the Screen to show more information on when and how much was paid. The operational flow is the same as the Expense Payout in the previous screenshot. I don’t have a Tutorial for this either …

That’s a shame - I have come so close, but I think it is just the account entries that are tripping me up. I’d really like to do it through the POS screen is possible since the calculation of the amount to pay can be very intricate. I think it would be too easy for an operator to just total up in their head the amount due and process a tranaction for that - but then when reviewing the transaction later it would not be possible to see the breakdown of what was paid and why.

I’ll keep trying with my hit-and-hope approach for now, but I am hoping that @Jesse could give me an idea of the accounting structure I should be expecting to see.

Look at the Tutorials. They show the Accounting setup. But using Products, POS/Ticket, and Payment screen for Payouts, while it might sound like a great idea, is sure to give you frustration. I have tried it, and it just isn’t designed to operate that way. It can probably be done in some fashion, but it is not the intended use of Tickets.

I also try to use vendor entity and ticket as expense here. I can’t get ticket/account to be negative (expense).

1 Like

You can still initiate from the POS screen and use prompts and automation to create transactions etc.
Entity screen will offer a more feature full /usable experience.
Think the point being not to use products and payment screen.

Although with the increased control over switching menus etc you might be able to work something out but if Q recommends that way chances are your better off taking his advice, he knows what he’s talking about.

1 Like