We have an agreement with each joint-venture project signatory and we need to “profit”-share according to the agreement terms e.g. a 70:30, 60:40 or 50:50 split of earnings after cost of production, shipping and other cost of sale expenses. Given this is for a Print-on-demand book with very little stock-in-hand then this Just-In-Time system is accounted for on a cash basis. The signatories may use either cash or accrual basis for their own accounting for what agreement revenues they receive as “profit” – that is independent of this agreement.
To track this for our Doctor Antonio book project we’ve decided to use Grisbi rather than spreadsheets or a more complex double-entry accounting such as GNU Cash or an online ERP system. Grisbi is a simple cross-platform single-entry accounting system that is Open Source. We are running version 0.8.6 built from source. It is file-based, single user (it locks the file) so this allows us to email this as a stand-alone file to the other party to the agreement.
We created 3 different cash accounts for the products, one for each of USD, EUR and GBP currencies that we are working (we do have both incomes (credits) and expenses (debits) in these three so it starts getting complex very fast).
We also created 6 other cash accounts for agreement payouts which we’ll explain later.
We created the “Categories” (what Grisbi calls the Chart of Accounts) according to what the agreement allows (which has no personal or routine office-like expenses).
Invoices or cash payments for items are debits from each product account according to the currency and have the Payee as “cash” or “createspace” or similar common destination.
Royalties or cash receipts are credits to each account according to the currency and have the Payee as “cash” or some specific common source e.g. “Amazon Royalty Payments”.
We do not put any customer data (i.e. personal data) in this file for data protection reasons.
At the end of the month each product cash account balance is split according to the agreement percentages. We track this payout process by doing a “transfer” (in Grisbi) from each of these three product cash accounts to one of the 6 Payment accounts that we have setup i.e. one of each of the three currencies for each of the agreement parties.
The agreement parties can now decide how they want to transfer monies between each party (to help reduce bank or Foreign Exchange charges) e.g. one party may keep the USD in exchange for the other party keeping a matching value in GBP or EUR so that we avoid paying bank charges and money transfer commissions, and each party can either leave the money in that payment account or cash it out.
To cash it out a debit is made against one special payee per currency per signatory which is for each agreement party to logically take the money out of the account in that currency.
Thus an agreement party can elect to only receive USD but hold it in the account until it hits a suitable large value to make it worthwhile based on bank charges, so we shuffle around the payouts as value matched transfers between the payout accounts (e.g. swap their GBP for our USD at a spot rate) and then at a suitable date charge a debit against that payout account to the special agreement payee in effect making money leave this set of accounts and giving it to the agreement party. They then account for this payment as they see fit in their own accounting system as a credit though note that deferring the payment on our agreement accounting system does not alter that once it is in the agreement payment account then the signatory has in effect had constructive receipt of this money from the point of view of their own tax returns for a particular tax year. Grisbi has a good reporting system that will allow a payee annual report to be run between any two dates and so allowing a report to be run for the differing tax and accounting years for the agreement signatories.
Managing trust with this: no accounting system will ever have any meaning if it can’t be trusted. By using Grisbi we can e-mail the Grisbi file to the other party. If either party desires they could compare the invoices for how much product with the sales returns for products to see that credits are being posted correctly. With no personal expenses allowed there is little opportunity for skimming into the agreement profit.
For simplicity sake one party agrees to manage the accounts for the agreement though potentially both parties could do this in isolation using the same input data and then compare the results per month. As the Publisher then Life Sign Press will be doing the accounts as per this documented process.
We have noticed a few minor bugs whilst testing Grisbi so we will be posting these onto the Grisbi bug tracker. The code seems to be mostly C and as we’ve had experience with debugging C for the GNOME Project Planner application it should be reasonably easy to advise the developers of the fixes.
Using Grisbi for agreement accounting.
We have an agreement with each joint-venture project signatory and we need to “profit”-share according to the agreement terms e.g. a 70:30, 60:40 or 50:50 split of earnings after cost of production, shipping and other cost of sale expenses. Given this is for a Print-on-demand book with very little stock-in-hand then this Just-In-Time system is accounted for on a cash basis. The signatories may use either cash or accrual basis for their own accounting for what agreement revenues they receive as “profit” – that is independent of this agreement.
To track this for our Doctor Antonio book project we’ve decided to use Grisbi rather than spreadsheets or a more complex double-entry accounting such as GNU Cash or an online ERP system. Grisbi is a simple cross-platform single-entry accounting system that is Open Source. We are running version 0.8.6 built from source. It is file-based, single user (it locks the file) so this allows us to email this as a stand-alone file to the other party to the agreement.
We created 3 different cash accounts for the products, one for each of USD, EUR and GBP currencies that we are working (we do have both incomes (credits) and expenses (debits) in these three so it starts getting complex very fast).
We also created 6 other cash accounts for agreement payouts which we’ll explain later.
We created the “Categories” (what Grisbi calls the Chart of Accounts) according to what the agreement allows (which has no personal or routine office-like expenses).
Invoices or cash payments for items are debits from each product account according to the currency and have the Payee as “cash” or “createspace” or similar common destination.
Royalties or cash receipts are credits to each account according to the currency and have the Payee as “cash” or some specific common source e.g. “Amazon Royalty Payments”.
We do not put any customer data (i.e. personal data) in this file for data protection reasons.
At the end of the month each product cash account balance is split according to the agreement percentages. We track this payout process by doing a “transfer” (in Grisbi) from each of these three product cash accounts to one of the 6 Payment accounts that we have setup i.e. one of each of the three currencies for each of the agreement parties.
The agreement parties can now decide how they want to transfer monies between each party (to help reduce bank or Foreign Exchange charges) e.g. one party may keep the USD in exchange for the other party keeping a matching value in GBP or EUR so that we avoid paying bank charges and money transfer commissions, and each party can either leave the money in that payment account or cash it out.
To cash it out a debit is made against one special payee per currency per signatory which is for each agreement party to logically take the money out of the account in that currency.
Thus an agreement party can elect to only receive USD but hold it in the account until it hits a suitable large value to make it worthwhile based on bank charges, so we shuffle around the payouts as value matched transfers between the payout accounts (e.g. swap their GBP for our USD at a spot rate) and then at a suitable date charge a debit against that payout account to the special agreement payee in effect making money leave this set of accounts and giving it to the agreement party. They then account for this payment as they see fit in their own accounting system as a credit though note that deferring the payment on our agreement accounting system does not alter that once it is in the agreement payment account then the signatory has in effect had constructive receipt of this money from the point of view of their own tax returns for a particular tax year. Grisbi has a good reporting system that will allow a payee annual report to be run between any two dates and so allowing a report to be run for the differing tax and accounting years for the agreement signatories.
Managing trust with this: no accounting system will ever have any meaning if it can’t be trusted. By using Grisbi we can e-mail the Grisbi file to the other party. If either party desires they could compare the invoices for how much product with the sales returns for products to see that credits are being posted correctly. With no personal expenses allowed there is little opportunity for skimming into the agreement profit.
For simplicity sake one party agrees to manage the accounts for the agreement though potentially both parties could do this in isolation using the same input data and then compare the results per month. As the Publisher then Life Sign Press will be doing the accounts as per this documented process.
We have noticed a few minor bugs whilst testing Grisbi so we will be posting these onto the Grisbi bug tracker. The code seems to be mostly C and as we’ve had experience with debugging C for the GNOME Project Planner application it should be reasonably easy to advise the developers of the fixes.