Accounting for sales, prepayments, payments tracking, COGS.
Keywords: Accounting for sales, payments tracking software, sales taxes, Cost Of Goods Sold.
Sales taxes (VAT, GST) imposed on a buyer are always extracted from sales revenue, and a seller has to remit them to tax revenue authorities. This rule is applied in all countries. For the USA see IRS 535 Business Expenses, Page 18:
...
CAUTION: Do not deduct state and local sales taxes imposed on the buyer that you
must collect and pay over to the state or local government. Also, do not include these
taxes in gross receipts or sales.
...
Bob should not apply sales taxes for frozen pizza, but here is used fake sales taxes for goods with cheese and all services (only for example purpose)!
To apply a sales tax for a material/merchandise/service you should:
1. Add a Tax (type must be "Sales (VAT)"!) e.g.:
2. Add a Tax Category e.g.:
3. Set a Tax Category for a material e.g.:
4. In the "Accounting settings" set "extract sales taxes from sales" to "Yes" and set ST aggregate rate to "Yes", this means that an item can have only tax, or in case "multi-taxes" it's used aggregate rate, this is the most used method. Then switch to "Yes" "Entries source #11 Sales Invoice, Debit Receivable per customer, Credit Sales taxes payable per tax for tax amount."
Bob received a prepayment for 50 USD from the "Mini Market" on Jan 16. Bob filled this "Prepayment From":
The full report of the posted document is:
Bob sold on Jan 17 6 Pizza with bacon frozen and 6 Pizza with cheese frozen to the "Mini Market" (he also sold 3 pounds of cheese and 1.5 hours of cleaning for example purposes). Bob filled this "Sales invoice":
The full report of the posted "Sales invoice" is:
After that the "Trial balance" is:
The "Ledger" of the "Inventory" account is:
As you can see Bob made another mistake. He set the Sales date less than the Manufacturing one for that pizza, so the balance of the "Inventory.Pizza Cheese Frozen" account is -18.93 (any minus balance is highlighted with red color) at 4:07 PM because it(pizza) was made at 6:36 PM. So it's reasonable to make the database copy more frequently. Just copy "bseis.sqlite" by a file explorer without exiting from the application (on Android use the application starting interface). For a warehouse's document the date means nothing because warehouse entries use the current time. And you can't withdraw a product or a material if it doesn't exist in the warehouse.
Payments tracking.
Bob received on 18 Jan the rest 107.64 USD from the "Mini Market" for the "Sales invoice #1":
It made these simple accounting entries:
After that, the sales invoice's payment tracking fields in the list are changed:
You can use the filter for the fields Payment total and Pay by date to report payments for sales:
Sales tax rounding mode.
Truly "Rounding" is "revealing the nearest number with reduced decimal places to the given (source) one". Both "Half-up" and "Half-down" give the nearest result, but "Half-up" is the standard.
Example for numbers: "20.215", "20.21501" and "20.21499", rounding to cents - 2 decimal places.
Half-up:
round(20.215) = 20.22, not 20.21
checking: (20.22-20.215)=0.005 equals to (20.215-20.21)=0.005
round(20.21501) = 20.22, not 20.21
checking: (20.22-20.21501)=0.00499 less than (20.21501-20.21)=0.00501
round(20.21499) = 20.21, not 20.22
checking: (20.21499-20.21)=0.00499 less than (20.22-20.21499)=0.00501
Half-down:
round(20.215) = 20.21, not 20.22
checking: (20.215-20.21)=0.005 equals to (20.22-20.215)=0.005
round(20.21501) = 20.22, not 20.21
checking: (20.22-20.21501)=0.00499 less than (20.21501-20.21)=0.00501
round(20.21499) = 20.21, not 20.22
checking: (20.21499-20.21)=0.00499 less than (20.22-20.21499)=0.00501
They like to introduce new methods in the financial sphere, including rounding. Method "CELL" is useful to make a "cent discount". Make sure about sales tax calculation rules in your country. If before rounding you have to rip decimal places to 3, then "half-down" of "20.21501" gives "20.215"->"20.21", so you save a cent. If you have to always round up all fractions after 2 decimal places, then "half-up" of "20.21499" gives "20.215"->"20.22", so you lose a cent. Because of it, Beigesoft™ EIS allows you to change the tax amount in any invoice.
If you have a choice between a standard thing and a new one, then you should better select the standard one to avoid problems.
Cost Of Goods Sold.
Here is used the most natural FIFO method. It's easy to understand and make it by computer. It's hard to make and track it by hand, unless you sell a few items per day. The average method is suitable when making it by hand i.e. without a computer. The LIFO is a little bit bizarre (it's hard to track) and it's lawless in many countries.
When we use items and make COGS entries, then we often face rounding errors. For example 120 eggs for 20 USD, price (rounded)=0.17USD, so withdrawal 119 eggs * 0.17USD = 20.23USD, that is no good. In old "Beige Accounting" you should use more decimal places for cost (price) to reduce the rounding error, and yet, a little rounding error (the rest) might occur in the "Inventory" assets account. That is price(cost) = 0.1667 * 120 = 20.00, so there is no remaining "the rest" in this and most cases. New COGS withdrawal algorithm allows to use the same precision (decimal places) for cost as price without any problem, the equation is:
IF items left - quantity != 0 THEN amount to withdrawal = round(total left / items left * quantity, price decimal places)
IF items left - quantity == 0 THEN amount to withdrawal = total left
e.g. 119 eggs to withdrawal, items left = 120, total left = 20, price decimal places = 2, so:
amount to withdrawal = round (20 / 120 * 119, 2) = 19.83
after that items left = 1, total left = 0.17
the rest 1 egg:
amount to withdrawal = total left = 0.17
To check this, just create a new test purchase (6 eggs for 4.29USD total) and one test sale for 96 eggs.
The "Purchase#1" (that was made before) has the rest of the eggs - 94 eggs for 15.66 USD:
New test "Purchase#2" 17 Jan has 6 eggs for 4.29 USD total (prior to the test sale):
* The field "Total left" is always zero for a new "item source line", it's cause of the used algorithm (because of complex cost revealing depends on used tax methods: item/invoice basis, tax included...), and it actually means that the "Total left" equals to "Total".
New test "Sale#3" full report:
Now the "Purchase#1" has no eggs left:
The test "Purchase#2" has 4 eggs for 2.86 USD left:
