CA / Accel accounting
Implementing statements of accounts
OBJECTIVE: Simplify communication between vendors and customers by focusing on total balance due instead of which invoices have been paid.
The following is quite basic accounting, so it might not seem worth reviewing at this level of detail. But we are going to implement the use of statements n all three entities (Accel, CA & ME) so it's important that we have a shared understanding of the fundamentals.
ISSUE: Some of our customers don't pay at the time we deliver goods or services to them. Most notably, US Embassy departments and CPS clients.
Also, we sometimes pre-pay vendors, like prepaid rent to our landlords, and construction costs to Vision M.
In both cases, significant time may pass between invoicing and payment (or the other way around). Sometimes payments are made in amounts that don't match particular invoices, either partially paying an invoice or paying multiple invoices in whole or in part.
With these clients, it seems we spend an inordinate amount of time and energy keeping track of how much is owed between the parties, and proving to the other party what amounts are currently owed.
We may also be tempted to take the same approach in inter-company contexts, like when CA supplies books, equipment or services to Accel, or when ME sells books to CA to resell to Accel.
It's time to streamline those processes by upgrading our reporting capabilities and changing our mindset.
BACKGROUND: Quickbooks tracks accounts receivable and accounts payable on an invoice-specific basis. That is, when a payment is made or received, it must be assigned to a particular bill (in AP) or invoice (AR).
That is a good practice for tracking AP and AR, because it enables the vendor to run an AR aging report to charge interest on the buyer's past-due invoices. We haven't started charging interest on overdue invoices, but when we do, this feature of Quickbooks will be useful.
BUT INVOICE-SPECIFIC REPORTING HAS A DOWNSIDE: We have some situations between vendors and customers regularly involving multiple invoices that stay unpaid for long periods, and irregular payments that don't match specific invoices. It can be very time-consuming to make the different companies' records agree on which invoices have been paid, and which are still owing.
This is especially true in situations where invoices have been retroactively adjusted and payments reassigned.
The good news is, there is another approach.
"STATEMENT OF ACCOUNT" APPROACH: A quicker way to understand the balance due from a customer to a vendor is to use a "statement of account". It's essentially a list that adds up all the invoices and subtracts all the payments, with the remainder being the balance due.
Here's a simple example of how they look:
This statement shows three invoices totaling $2250 and one payment of $2000. This leaves a balance due of $250 at the end of the month.
Here's the next month's statement between the two same two parties:
The balance owing of $250 is brought forward from the previous month. Two new invoices totaling $3000 are added, and no payments are received. Thus, the ending balance is $3250.
One more month:
You see how it works. Pretty basic, old-school reporting format.
If the vendor and client are having trouble agreeing on how much is due, you can run a report that starts at a time when both agree on the balance owing (even at the very start of the relationship, with zero balance due). The report shows every invoice and every payment since that time. Like this:
It's the same 10 transactions from the previous 3 months, just combined on one statement. The final balance due is the same.
If the vendor and the client disagree on the balance due, they can just review the list of invoices and payments, looking for discrepancies and settling issues like "this invoice is for ten students, but only 8 attended" or "you are missing one of our payments -- here's our bank statement as proof".
But they DON'T have the additional burden of trying to agree on which specific invoices have been paid and which have not. It doesn't matter if one party applies a certain payment to one invoice and the other party applies it to a different one. What matters is the "bottom line" balance due.
THE BUCKET METAPHOR: It helps me to think of AR and AP accounts as buckets. Water flows in when invoices are posted to the account, and water flows out when payments are made. When all the invoices have been paid, the bucket is empty (balance due = zero).
A Statement of Account is a way to see the invoices going into the bucket (increasing the amount the customer owes to the vendor) and the payments going out of the bucket (decreasing the amount the customer owes).
I understand that in our campaign to collect from the Embassy, presenting the invoices and payments for each department in this format helped break the logjam. It’s a simple, time-honored format to quickly create a shared understanding of how much was due, how much has been paid so far, and the balance remaining to be paid.
PAYMENTS STILL MUST BE APPLIED TO INVOICES/BILLS: That must be done inside each company's books. All I'm saying is that (for now) it doesn't matter if the client and the vendor apply the same payments to different invoices.
When we later start charging interest on past-due accounts, it will be more important to have a shared understanding on which specific invoice has been paid. That's why we should always...
PAY THE OLDEST INVOICES FIRST: If both parties always follow the standard business practice of assigning each payment against the oldest open invoice at the time, their records would line up exactly. If the vendor does this faithfully, the customer has no basis for arguing the interest has been wrongly calculated. If both parties follow this general rule, any issues about the amounts of invoices or payments, or missing transactions, should be easy to spot.
[Side note: When we retroactively change or add invoices, there's always the question of whether to go back and change the application of payments to 'pay' the 'older' invoices that have been newly added. In most cases for now I think it will be ok to leave the 'gaps' and then fill them in with the next payments that come in. We'll get caught up and this problem will be very rare in the future.]
CAN QUICKBOOKS PRODUCE THIS KIND OF REPORT?
For vendors who are invoicing their customers, yes it can! Following these instructions, I printed the example below (selected "Balance Forward" statement type, and started the date range earlier than the first invoice).
Unlike the examples above, the invoices and payments are combined into one column, with payments indicated by negative numbers, that is, reducing the balance due:
Kind of weird that it puts the summary at the bottom of page 1, even though transactions spill over on to page 2. But it shows the info we're looking for. And of course you can select any date range that is most appropriate to the purpose of the report.
I believe you can automate the creation of these statements, or at least do them in batches. They provide a visual history of invoices and payments that will support our efforts to collect from customers.
In extreme payments, the statement can be accompanied by an A/R aging report to call further attention to how long we have been waiting to be paid, and to justify the application of interest on past-due accounts when we implement it. The A/R aging report for the same customer as above looks like this:
Note that the A/R aging report shows only open invoices (invoices not completely paid, according to how the vendor has applied payments received from the customer). It doesn't show paid invoices or the payments that were applied to pay them. For that very useful info, you need the Statement of Account.
Our clients who are behind on payments should be getting a statement from us every month, with the more tardy ones also receiving an A/R report.
So for we've been talking about statements of accounts we, as the vendor, will send to our customers. But...
WHAT IF WE ARE THE CUSTOMER AND NEED A STATEMENT FROM OUR VENDOR? Ideally, the vendor should provide the statement to the customer. Regular statements would be a very useful tool in communicating with Vision M and the Archdiocese (Bethanie rent) about the status of our payments. But those two vendors aren't likely to start preparing statements for Accel. For Bethanie rent, we may even need to create the invoices for them so we can enter them as bills in Accel's books.
So Accel can create basically the same thing by running a Quickbooks report called "Transaction List by Vendor" (filtered for the targeted vendor and date range). You get a list of bills and payments, and you have to manually add the column that calculates the balance.
To illustrate, I ran the report on the account between Accel and Vision M (filtered for "All Dates"; the records were current to 13 Nov 2023). Here's how the top several rows appear (fields highlighted in yellow were added by me):
You can see the unusual pattern of activity between Accel and Vision M, with very few, large bills from Vision M and a high number of payments from Accel.
You'll see at the bottom of the report (below), Accel had just paid $150k to Vision M, so in mid-November Vision M owed a credit of $148k to Accel (i.e. Accel had overpaid or prepaid Vision M). I'm sure with the heavy renovation work going on at Bethanie, that credit is much lower now (reflected by a smaller negative value in the report).
Click here to download the Excel file with the complete report.
Producing this vendor statement requires a little manual intervention. Maybe our Quickbooks experts will know a better way to produce the info.
Luckily we have only a small number of vendors who will need this kind of attention. Not just the two big ones already names; this can automate calculations of our status with other long-term accounts like SIEFAC, Securico, and the people who provide fuel for the generator, the split A/C units, etc.
The Kinshasa staff is already tracking these relationships in their own private spreadsheets for use in communicating with the local vendors. Our objective is to upgrade our financial operating system in 2024 so Kinshasa can get timely, accurate info straight from Quickbooks. Read about how we plan to achieve it here.
AND WHAT ABOUT THE INTERCOMPANY ACCOUNT?
We have only one. CA/Accel.
Everything between CA and Accel goes into that one account. Especially CA invoices for SS, and Accel pmts to MagicTouch obo CA, credited in Interco as a payment against CA invoices for SS.
Everything? Or just the strange things of journal entries? Study it. Look for invoices and payments outside of it.
The register IS the statement, just like a bank statement is basically a one-month section of the register, with a starting and ending balance.