Recommended accounting guidelines

This paper describes a possible concept for accounting policies for Vertec in larger service companies.

The invoice of a project (or a project phase), on which time and materials are charged, is posted directly to the customer’s receivable account and to one (or more) revenue accounts:

The debtor payment is handled by the accounting software (1) (and is the same for all types of settlement described):

For Vertec, it is important to know what costs are incurred for each service entered (2). It is therefore crucial to distinguish between invoices which include services directly corresponding to costs and invoices relating to advance payments or payment plans. Such advance or payment plan invoices are always posted as a customer advance to a liability account.

This section describes the case of an advance payment on a project by hours.

Advance invoice:

After (for example) one month, we have worked on this phase for 500 and charge this to the customer. Vertec generates a new invoice for 500, and matches this invoice with the advance payment (3):

Next month we are working for another 800. Since the rest of the downpayment is only 500, the customer has to pay 300:

Alternatively, let’s say we only worked for 300. The rest of the downpayment is now 200, the project is completed and we have to pay back the 200. Vertec does this through an “advance equalization”:

For expense projects that cannot be charged monthly, as well as for lump sum projects, the project value is activated. For services rendered, the project value is calculated using the Percentage of Completion (PoC), usually using a cost-to-cost method. For expense projects, the value of services can be the sales value. For expenses and materials (such as licenses), the sales or purchase value is taken.

Accounting standards such as IFRS / IAS and Swiss GAAP FER also require long-term orders to be defined according to the PoC method (IAS 11 on production orders, Swiss GAAP FER 22 Long-term orders).

There are basically two methods for a monthly income statement:

1. Project values are posted early in the new month before any invoices are issued for the completed month. Value date is the last day of the completed month.
2. The project values are resolved on the first day of the current month.
3. Invoices that fall within the completed month are posted with currency invoice date to the current month (NOT the last day of the completed month).

1. All invoices for the last month are issued. The value date of the invoices is the last day of the completed month.
2. When the invoice run is completed, the project values are calculated and posted. Value date is the last day of the completed month.
3. The project values are also resolved on the first of the up-to-date month.

These two variants differ substantially in how the income statement is presented for a month, but not so much in what is posted by Vertec – the only difference here is the value date of the invoices.

That is why in this paper we only elaborate one method – “Quick Closure”. As an example, let us assume that a lump sum project with a total value of 1500 has been sold and is payable in 3 instalments of 500. The instalments are charged and posted as advance payments (at most to a different liability account than “pure” downpayments):

The charging of the other two instalments is posted immediately.

After the first month, the PoC of the services yields a project value of 800. We post this value as income with a value date of the end of the month:

On the first of the next month, the value is resolved again:

Now let’s assume that 300 will be added to the project value in the following month. Since we have resolved the entire activation, we now activate the total amount of 1100, and the revenue account shows a total revenue of 300 in new month.

This process is repeated as long as necessary. Vertec (and the accounting software) needs a final invoice to complete the lump sum project, which may or may not be sent to the customer:

(1) Subsidiary book Receivable accounts.

(2) Otherwise, it cannot be assumed that (e.g.) the benchmarking module can provide a meaningful evaluation of the performance of a project or employee.

(3) This happens regardless of whether the invoice is paid or not.