Payment models

Introduction

In TimeLog, there are eight payment models. Your edition of TimeLog is crucial to how many of the eight models you have access to.

Description

There are four payment models based on time and material and four based on fixed price. You can mix the payment models on a project as you please, and in that way handle both fixed price and time and material on the same project.

For all models, except prepaid hours, is it possible to specify how the distribution of revenue should be on work, expenses and travels.

The four time and material models

Common for all time and material payment models, except prepaid hours, is that it is possible to set an upper limit for invoicing. If this limit is exceeded, the estimated hourly rate is set to EUR 0, and the hours will appear with a 0 value when invoicing.

Standard agreement

With this contract model, you invoice hours x rate. All billable hours are shown automatically with invoicing, as long as there are no contract overruns (if set up).

On this contract model, it is possible to set up a notification, which sends an e-mail to the project manager when a certain percentage of the hours on the contract are spent.

On account with end-balancing

With this contract model, you continuously send one or more payments to the customer. You register with hours x rate. Hours are not shown when invoicing before the contract ends; it may continuously be recognised as revenue with Revenue recognition.

When the contract is set to completed, a minus payment corresponding to the sum of the on account invoiced payments x -1 is generated.

On the final invoice, the negative on account payment record and all the hours are shown. The differential is the amount the customer must pay or receive.

On this contract model, it is possible to set up a notification, which sends an e-mail to the project manager when a certain percentage of the hours on the contract are spent.

On account with periodic balancing

With this contract model, you send one or more fixed (e.g. monthly) payments to the customer. When the invoice is booked, a minus payment corresponding to the sum of the payment x -1 is automatically generated.

You register hours x rate.

When the period is completed, the hours, the created minus payment and potentially the next periodic payment are shown on the invoice. The differential is the amount the customer must pay or receive.

Prepaid hours

On this contract model, the customer pays for the work in advance.
You register hours x rate.

The registered hours are shown during revenue recognition (with the module Revenue recognition), and are never shown when invoicing.

On this contract model, it is possible to set up a notification, which sends an e-mail to the project manager when a certain percentage of the hours on the contract are spent. The project manager is also notified, if more hours than paid in advance are recognised as revenue.

It is not possible to register expenses or travels on a prepaid hours agreement.

The four fixed price models

Common for all fixed price payment models is that payments are invoiced, never the hours. The hours may be recognised as revenue.

Standard agreement

With this contract model, you invoice one or more payments. You may create separate standard agreements per project with each project having its own payment plan.

On this contract model, it is possible to set up a notification, which sends an e-mail to the project manager when a certain percentage of the hours on the contract are spent.

Continuous service contract

With this contract model, you can invoice small periodic fixed price projects, e.g. service agreements.

A repetition pattern for invoicing is set up where you define

• The continuous payment
• The period the payment covers
• First invoice date
• Product number
• The payment text, which is the text being added to the invoice. If you click the info icon, you have the opportunity to insert tags adding information from the project: <#PaymentPeriodStart#>, <#PaymentPeriodEnd#>, <#Month#>, <#Year#>, <#InvoiceDate#>
• The contract’s start and end dates. If the end date is unknown, you do not need to enter a date
• The monthly work budget
• The target hourly rate, which is what you expect to earn per hour, and it is used as basis for calculating depreciations

In the section Monthly revenue distribution, you can control how the period’s revenue is distributed between work, expenses and travels registered on the project. In this way you ensure the hours’ value do not exceed what you have allocated here, in case more work is done than what you budgeted.

If needed, you can add an odd start-up period. It is used when the work on the project starts before the repetition pattern on the contract, and the customer has to pay for the start-up period.

An example: You have a contract, where the customer is invoiced 1. January every year. The contract starts 15. September and you would like to invoice the customer for the period 15. September to 31. December followed by an annual payment.

When the contract is saved, the payments for the next 18 months or until the end date of the contract is automatically created. The payments are added on an ongoing basis as the project progresses. It is also possible to merge several payments, if the customer has to pay up front for a longer period.

These payments are used to calculate the cash flow in reports, e.g. Payments plans – overview.

When time is tracked, the value is calculated based on the budget and the payment linked to the period.

Task driven revenue

On this contract model, a payment plan is created as a normal fixed price project. On the task, you may enter what value each task should get from the invoiced value. The budgets and progress on each task decide what value the single hour receives.

One or more tasks can be marked as fixed price tasks and thereby linked to one payment in the payment plan. In this way, the tasks receive the value from the payment distributed on the hours placed on the tasks.

On a task you may mark if the value added to the tasks (and potential sub-tasks) are managed via the payments’ task association in the payment plan.

In this way, you can chose that a payment is associated with such a marked task. This is useful for managing deliveries, which can be broken down project related and linked to one or more payments on such a delivery.

On this contract model, it is possible to set up a notification, which sends an e-mail to the project manager when a certain percentage of the hours on the contract are spent.

In the section Monthly revenue distribution, you can control how the period’s revenue is distributed between work, expenses and travels registered on the project. In this way you ensure the hours’ value do not exceed what you have allocated here, in case more work is done than what you budgeted.

Continuous item invoicing

With this contract model, the customer pays per transaction and not per hour. A recurring payment may be determined based on an in advance fixed number of goods for invoicing.

Payments may include pc. and unit price, e.g. 20 payslips of EUR 27. A value distribution is possible, so only a part of the value is placed on the hours in case the payment also include other expenses such as software licenses or other things.

With our API it is possible to make an automatic update of the number of units for invoicing.

When you create a new contract, a repetition pattern for invoicing is set up where you define:

• The quantity and price per unit
• The continuous payment
• The period the payment covers
• First invoice date
• Product number
• The payment text, which is the text being added to the invoice. If you click the info icon, you have the opportunity to insert tags adding information from the project: <#PaymentPeriodStart#>, <#PaymentPeriodEnd#>, <#Month#>, <#Year#>, <#InvoiceDate#>
• Work per unit (h)
• Direct costs per unit, if you e.g. pay licence costs
• If expenses should be added to a specific employee, expense type and payment method automatically
• The contract’s start and end dates. If the end date is unknown, you do not need to enter a date
• The monthly work budget in hours
• The target hourly rate, which is what you expect to earn per hour, and it is used as basis for calculating depreciations

In the section Monthly revenue distribution, you can control how the period’s revenue is distributed between work, expenses and travels registered on the project. In this way you ensure the hours’ value do not exceed what you have allocated here, in case more work is done than what you budgeted.