skip to content
 

All invoices for sales must be raised on UFS, unless written permission is given by the director of Finance and be in the name of the University of Cambridge showing the University's VAT number.

Determining the correct currency to use

Detailed guidance on how to raise invoices on UFS is provided on the web.

Transactions should be raised in the currency of GBP whenever possible. Sales made to customers in foreign currencies may result in a loss in value in the GBP equivalent due to market exchange rate fluctuations. Banking of foreign currency will result in the Department incurring related bank charges.

Exchange rates for a number of foreign currencies are pre-loaded into UFS each month. This action is to facilitate payments made to foreign Accounts Payable Suppliers and should not be seen as authorisation to raise Accounts Receivable transactions in foreign currencies.

The exceptions to the above guidelines are:

  • US Dollar (USD)
  • Euro

The University holds bank accounts for both of these currencies and therefore cheques received will be banked directly into the relevant accounts. Transactions may be raised in these currencies without further charges to the Department. If you know that the customer will be settling in either USD or Euros then raise the invoice in the corresponding currency using the corporate rate as identified on UFS.

Timescales

It is the department's responsibility to ensure that all invoices comply with VAT regulations and are raised promptly -certainly not more than one month subsequent to the transaction to which it relates. For example:

If the sale takes place on the 15th June then the invoice must be raised by the 31st July.

The University's policy is:

  • For supplies of goods, invoices are raised as soon as the goods are delivered with payment terms of 30 days from the invoice date.
  • For supplies of services, invoices should be raised monthly in advance, the first two months being payable on commencement of the contract. Again 30 days payment terms are then applied from the date of the invoice.

Payments in advance
These are the exception to the rule. If payment is received before the goods are delivered or the services are performed and an invoice hasn't already be raised then you must raise the invoice when you receive the payment.

Deposits and stage payments
If you decide to ask for stage payments or a deposit, then an invoice should be raised for each instalment and the narrative on each invoice should clearly state this e.g. '25% deposit' ; 'instalment 2 of 3', 'final balance'

Posting to the correct accounting period
Additionally, departments should endeavour to post invoices to the General ledger accounting period that reflects when the actual goods were delivered or service performed. So for example:

We provide some work to a customer on the 23rd May
The invoice is raised and dated on the 3rd June
But on UFS it is posted back to the May GL accounting period.

You are able to back post for as long as the AR module is open for the previous month (currently open for 3 working days after the month end). Simply change the 'GL date' on the invoice header screen within UFS but ensure that you leave the invoice date as the current date.

Account codes

Within UFS each invoice line has three account codes allocated to it:

  • Receivables account - The University's debtor control account (do not change)
  • Tax account - The University's VAT account (do not change)
  • Revenue account - The departmental account that must be specified

Departmental AR users will need to specify for each invoice line the appropriate revenue account that the sale will be attributed to in their accounts. They can select the cost centre of their choice but:

Source of funds = GAAA (External Trading)
Transaction code = must be selected from the K or L range

Recharges

The terms 'recharges' and 'reimbursements' are commonly used inter-changeably however, for taxation purposes they are treated slightly differently. Please see VAT & Other Taxes pages the Financial Procedures Manual.

If you are recharging an external customer for goods or services that your department has previously received from a supplier then there are two separate transactions:

  1. Between the original supplier and your University department.
  2. Between your department and your customer.

Original Purchase
There are three options:

  1. If at the time of acquisition the department knows that the goods/services are to be passed on and recharged to an external customer then they should ensure that their Accounts Payable invoice from the supplier is coded to source of funds GAAA and the appropriate E transaction code. OR
  2. Post purchase, create a GL journal to transfer the cost to the correct source of funds code:
    • Credit: the original source of funds and transaction code.
    • Debit: source of funds GAAA with the original transaction code.
    • Save and post the journal. OR
  3. Adjust the original AP invoice if it was originally paid for out of a research grant:
    • Remove: the existing distribution line for the item in question on the original accounts payable invoice by entering a corresponding negative line (including the project coding fields).
    • Enter: a new line in the AP invoice distributions, coded to sourceof funds GAAA with an appropriate E or F transaction code.
    • Validate and secondary approve the invoice again.

Subsequent resale
A sales invoice should then be raised in the normal way using an appropriate L transaction code to describe the supply and the source of funds code GAAA.

Donations
Occasionally, you may be asked to provide an invoice to a benefactor to document for both parties, the monies pledged. Although, donations are not technically a 'sale', this practice is accepted within the University. In these instances:

  • Ensure that it is clear on the invoice that it relates to the receipt of a donation.
  • The tax rate is 'outside the scope'.
  • An appropriate source of funds code in the E or H range is selected.
  • A transaction code beginning with LF?? is used.

Feedback

Feedback

If you have any comments or spot any errors or omissions on any page please let us know using this form.

Read more