Crediting and debiting accounts in sambapos - not same as official accounting?

I’ve been trying out the accounting system in SambaPOS and I just don’t seem to get it…
I did some reading on accounting and credit/debit accounts, and for some reason it seems like SambaPOS is not behaving the way official accounting works, or maybe I’m just missing something here…

Normally credit/debit accounts work like this:
assets (cash etc)/expenses/losses are put in a debit account
liabilities/revenues (sales)/profits/gains are put in a credit account

when you debit a debit account or credit a credit account, you are increasing its balance
when you debit a credit account or credit a debit account, you are decreasing its balance

When I try this in SambaPOS, it doesn’t seem to behave like that at all. It just sometimes increases the account and sometimes decreases it (not depending on whether it’s a credit or debit account type).

Can somebody explain to me what exactly happens with the Account Type parameter Rule (debit/credit) and debiting/crediting an account through Account Transactions?

Also, when an Account balance is put between brackets, does this mean it’s a negative balance?

I will refer you to a conversation I have had with other people on this.

YOu are trying to read accounts screen like its an accounting report… it is NOT an accounting report. Its a process. It uses Transactions and documents.

Credit and Debit are placeholders for documents and transactions to put values into.

Transaction A puts 300 into Account Dog:Credit… Account Dog’s Balance reads (300)
Transaction B puts 300 into Account Dog:Debit… Account Dog’s Balance reads -
Transaction C puts 300 into Account Dog:Debit… Account Dog’s Balance reads 300

OK now that you got that understanding… lets get little more complex…

Account Dog has 300 in Debit, 0 in Credit so balance is 300

You want to move money from Account Dog into Account Cat. Account cat has 0 in credit or debit

You make a transaction that puts 300 into Account Dog:Credit which makes Account Dog’s balance -
That same transaction puts 300 into Account Cat:Debit so now Account Cat’s balance is 300

Account Cat Debited the money from Account Dog which is why its under Debit for account Cat… To make account Dog’s balance correct you had to put a value into Credit to balance it.

If you want to understand the accounting… then try not to relate the words Credit and Debit in a literal sense… instead try to understand the process. Credit and Debit do have actual value and they mean what they say, But you are looking at the accounting screen wrong.

(BALANCE) = negative yes

The Account Type (Debit/Credit) parameter is for creating entity accounts. You can have a Credit based Customer account or a Debit based Customer account. Debit Customer Account = predefined balance to pay from when buying goods. Credit Customer Account = Charge account.

1 Like

You must be missing something because this is how Samba is working

Sales go in as a Credit and = (Balance) Which is exactly as you described in: [quote=“pipo, post:1, topic:2385”]
liabilities/revenues (sales)/profits/gains are put in a credit account

Cash goes in as a Debit which = Positive balance Which is exactly as you described in:

The Credit/Debit portion of Account Type mixes a lot of people up. Its not there to define the direction the account is going in the accounting screen. Its there to define type of account for an entity.

Thank you @Jesse for the elaborate explanation. I’ve read it several times and I’m still a little foggy about it, but I think I’m getting closer.

What I (think I) understand now is:

  • a balance between brackets means a negative balance

  • crediting an account (or putting an amount in the account’s credit as you call it) decreases it’s balance

  • debiting an account (or putting an amount in the account’s debit) increases it’s balance

  • the Sales account represents things you sell, so these things or sales have to decrease when you sell (by crediting the sales account)
    while your Cash account represents money you get for it, so the Cash account has to increase (by debiting it)

  • the credit/debit parts in the accounts screen are just placeholders for the Transactions and Documents, and have nothing to do with credit/balance accounts in classic accounting.
    They put an amount in the credit part to decrease the balance of the account, or put an amount in the debit part to increase the balance.
    After one or more transactions have been made, the credit part is subtracted from the debit part to get the account balance

  • the credit/debit Rule parameter in Account Type also has nothing to do with credit accounts and debit accounts in classic accounting, but specifies what the balance of the accounts created means when making payments in the payment screen: “outstanding payment” (debit) or “prepaid amount” (credit)

Am I getting warmer?

This must be wrong I think because when you add funds to a SambaCard after setting the Account Type’s Rule parameter to “credit”, the balance of the SambaCard Account becomes negative. So the amount balance here probably means “outstanding payment” after all? Are these parameters values switched?

What happens when you choose “default” for the Account Type’s Rule parameter? How does the system decide whether it’s “credit” or “debit”?

Adding funds to a SambaCard account that is set as credit… is same thing as making a payment on a credit account. This is why it would become negative.

Adding funds to a SambaCard account that is set as Debit would increase its balance… its a debit card…

If you are making a non entity Account Type just set it to default… if you are making an entity Account Type you choose if its Credit or Debit.

I’m starting to understand the accounting system a bit now. It’s actually not that different from classical accounting. Only the way it is operated in SambaPOS is a bit different.


Credit and debit accounts are technically the same thing in SambaPOS.
If you want a credit account, you make sure it always has a negative balance.
If you want a debit account, you make sure it always has a positive balance.
So, accounts with a balance between brackets are credit accounts and the other accounts are debit accounts.

credit accounts (negative balance):

customer accounts
SambaCard accounts

debit accounts (positive balance):

bank accounts

To understand the accounting system better, you have to realize when you see negative numbers (balance between brackets), that doesn’t really mean the amount is negative. It means it’s a credit account. There’s a difference between the amount shown and its ‘absolute value’, which is the actual amount no matter if it’s positive or negative.
That the Sales account balance is between brackets does not mean you have negative sales, it means it’s a credit account like in classical accounting.

Account statements/transactions

Taking money out of an account or adding to it, you can do with an account transaction.
Account transactions take money away from the source account and add it to the target account.
They put the amount in the ‘credit’ field of the source field and also in the ‘debit’ field of the target account.

To ‘debit’ a credit account or ‘credit’ a debit account like in classical accounting you have to select the account in the ‘source account’ field of the Account Transaction.
This will add the amount to its ‘credit’ field, causing the balance to decrease.
For a credit account this means its ‘absolute value’ (amount without brackets) will go up.
For a debit account this means its ‘absolute value’ (amount without brackets) will go down.

To ‘credit’ a credit account or ‘debit’ a debit account like in classical accounting you have to select the account in the ‘target account’ field of the Account Transaction.
This will add the amount to its ‘debit’ field, causing the balance to increase.
For a credit account this means its ‘absolute value’ (amount without brackets) will go down.
For a debit account this means its ‘absolute value’ (amount without brackets) will go up.

So, for increasing/decreasing the ‘absolute value’ of an account:

to increase the ‘absolute value’ of a credit account (Sales, SambaCard, etc):
you select the account in the ‘source account’ field of an Account Transaction

to decrease the ‘absolute value’ of a credit account (Sales, SambaCard, etc):
you select the account in the ‘target account’ field of an Account Transaction

to increase the ‘absolute value’ of a debit account (Cash, Receivables, etc):
you select the account in the ‘target account’ field of an Account Transaction

to decrease the ‘absolute value’ of a debit account (Cash, Receivables, etc):
you select the account in the ‘source account’ field of an Account Transaction

Your getting it! He simplified it basically. Traditional accounting is VERY complex. This system is a very simple accounting system. Most people are used to reading accounting reports and do not see the underlying system that actually holds the accounting.

Now that you get that part… you can see that it truly is traditional accounting… its just been reduced down and simplified so you can use it like a report if you need too.

I am never sure if someone truly knows accounting or not when I see questions about accounting on here. So my responses are designed to get them to understand how to get the system to give them the results they want. If I was to try and explain accounting in accounting terms it would just confuse people even more.

You sure are right about that. I’ve studied some accounting in college (although that’s long enough ago that I had to read up on it again), and it is not very natural to say the least.
But I think the SambaPOS system is also not extremely easy to understand. When you don’t know about the negative values for some accounts and positive values for others, it depends on whether you understand accounting or not: if you don’t, you will have absolutely no idea what to do with it without good documentation (or a lot of help on the forum), and if you do, you will think it must be the same (and apply the same accounting rules you know and get very confused when it doesn’t work).

But anyway, now that I’m finally starting to get it, I can’t wait to start using it to set up my system. Thank you @Jesse for getting me on my way, it sure helped a lot.

I hope this thread will also help others who are trying to make sense of SambaPOS accounting.

Samba does not have an extensive documentation… but it does have a thriving community. In ways I prefer the community. Documentation will come in time. Hopefully support grows enough so they have enough resources to do those type of things.

SambaPOS is easy to understand if you need a basic setup and do not want to mess with it… if you want SambaPOS for what most people want it, To customize it to their own business needs, then yes it can be quite complex. But remember that with most POS software you get the easy to understand portion but you do NOT get the customize to your own business needs like you do in SambaPOS.

So honestly in regards to what SambaPOS was really designed to be… its alot less complex than almost all of the other solutions out there. You do NOT have to be a programmer to set it up and configure it specifically to your business.

SambaPOS is an absolutely amazing piece of software, there’s no doubt about it. And I think better documentation would make it even a lot better.

A separate forum category just for documentation would be interesting to have. That way users trying to figure things out could add to the documentation, that could really speed up the whole process of making documentation if you ask me.
If everybody contributes a little bit to it from time to time, SambaPOS could have great documentation in no time.

All that would be needed is a separate thread for every part of the system (like chapters), and one main post per thread (which is the documentation for this topic).
When users want to add to it or suggest mistakes or changes, they just post a reply and the original poster can make the changes.
There would of course have to be a main post (with the document structure or index page) and some style guidelines, but those don’t have to be very complex (anything is better than no documentation).

An alternative would be to set up a wiki page for it (although I’m not sure that would make people contribute to it as much as having it here on the main forum).

Do you think this documentation can help people understand how it works?

We have wiki support if anyone interested in helping us in documentation I can organize that. For example instead of answering a question we can update related document and give a reference to it. How it sounds?

I’m not sure if a wiki would be better than just a separate category on this forum. Sure, wiki’s are made for exactly this, but they also have some advantages:

  • separate website (when people want to find something out, they would have to look on the wiki AND on the forum for many things, especially in the beginning when there’s not much on the wiki that could be a bit of a hassle) unless you can link the search function for the forum and the wiki
  • separate login and password, which may be just to much hassle for some people to bother for a small change to the documentation
  • a bit more complex to use than the forum posts here
  • no forum messages (/questions). When people don’t understand something completely on this forum, they can ask questions and discuss it on the corresponding topic page, which will lead to a better explanation

I don’t know, I think maybe better would be to start by putting it on the forum and once you have a substantial amount of documentation for most topics, then you can still move it to a wiki.

Of course that’s just my opinion, you may want to see what other people think…

I’m so sorry @pipo. I meant forum has wiki support. I’ve created a test topic here.

Alright, I see what you mean. That could work, but is it like anybody can make these changes in real-time without any moderation or anything?
Shouldn’t there be somebody who controls the page to make sure it is understandable and correct?

I can also create a specialized group that can edit posts under a specific category but I believe we should think about it if permitting anyone does not work. We can see whole change history so if we can roll back to previous version when needed.

Also I’ve increased wiki editing permission to trust level 2 so only users that have some real activity will be able to edit it.

That sounds good. Sure, we should try that out.
Then you only need to make some kind of structure for like an index page (like you would have in a software book for example):

  • Introduction
  • Requirements
  • Installation
  • User interface
    – login screen
    – POS
    – …
  • Setting up your (basic) customized system
    – departments
    – menus, products, recipes and ingredients
    – …
  • Advanced functions
    – Actions, Rules & Triggers
    – Entities
    – …

otherwise it’s just going to be a whole bunch of topics, but no real structure…

It would also be important to differentiate documentation for V3 and V4 I think…
Either mention under each topic when something is V4 only (or how it is different in V3 and V4) or have 2 different categories.

Until there’s multilingual support in V4 that is :wink: .