Accounts payable
Accounts payable includes the receipt, recording, review, approval, and payment of supplier invoices, ensuring that invoices are accurately registered, properly approved, and paid on time.
When electronic invoice processing is set up for an institution, the default process is as follows:
Suppliers send invoices electronically to Orri. It is recommended that a representative of the institution contact the largest suppliers and request that they send invoices in electronic format.
Invoices are received automatically from suppliers in Orri and imported into Accounts Payable (AP).
The posting engine attempts to assign accounting information to the invoices. If this is not possible, the invoices are imported without accounting information.
The accountant:
checks whether the invoice is correct and relevant to the institution
completes the accounting information. The accountant reviews or corrects the posting engine’s suggestion, if available. A contact person at the institution can edit the reference, dimension and text in the invoice endorsement. See the instructions for institution staff who take part in endorsing invoices
confirms the invoice and sends it into the approval process
regularly searches for invoices that have stopped in the process or have been rejected
The accountant is responsible for ensuring that invoice approval is completed.
The approver receives a notification from Orri that an invoice is waiting for approval.
The approver signs in to Orri and reviews the invoice:
if the invoice is rejected, the approver must give a reason or add a comment
a rejected invoice is returned to the accountant. A contact person at the institution must request a credit note or confirmation from the supplier that the invoice may be cancelled
an approved invoice is sent to the cashier, who pays the invoice on the due date
The Orri posting engine creates accounting entries
Posting allocation rules
A posting allocation rule describes how an invoice should be split between accounting strings. The invoice amount is split between them according to the proportions specified in the rule.
All invoices relating to the government’s purchase of goods and services must be electronic. PDF invoices sent by email are not accepted. How to send an electronic invoice Electronic invoices must be in XML format and sent via a message broker or the PEPPOL network. The Financial Management Authority receives electronic invoices on behalf of most government institutions. Suppliers can send invoices by:
issuing an invoice in their own accounting system and sending it via a message broker
sending an invoice through the PEPPOL network
using the Financial Management Authority’s registration page if they do not have an accounting system
Accounting system providers and message brokers can assist with issuing and sending electronic invoices. What is an electronic invoice? An electronic invoice is a machine-readable document in XML format. It meets the technical requirements for electronic invoices and enables computer systems to read, process and store invoices automatically. Electronic invoices:
simplify receipt and processing
reduce manual work
improve traceability
are more environmentally friendly than paper invoices
can be used both in transactions with the government and in the general market
A PDF document sent by email is not considered an electronic invoice in this context. What information must invoices include? Invoices to the government must include the necessary information so that they can be processed and paid. Invoices must include:
a description of the goods or services
the price of the goods or services
all costs incurred
a bank account so that payment can be made by bank transfer
the due date
the final due date, which must be the same as the due date
Fees that have not been agreed may not be added, such as paper billing fees or service charges. If an invoice does not refer to an order or project, it is advisable to include information about a contact person or department. Payment terms Payment terms must be in accordance with the applicable contract. If no contract has been concluded, the government’s standard trading terms apply. Payment notifications to suppliers Suppliers can receive a payment notification once an invoice has been paid. Payment notifications are sent as:
a PDF document by email
an XML document for those who wish to automate the receipt of payment information
A credit note is used to correct an invoice that has already been issued.
It can reduce or cancel the amount on a previous invoice.
When should a credit note be issued?
A credit note should be issued when:
Goods are returned
A service was not provided in full
The wrong price was charged on an invoice
A discount was missing from the invoice
An invoice was issued incorrectly
Too much was charged
An invoice was issued to the wrong customer
What information must be included?
A credit note must refer to the original invoice.
It must clearly state the amount that is to be deducted or cancelled.
Invoice Number
A credit note must have its own invoice number.
It must not have the same invoice number as the original invoice it refers to.
Procurement cards are intended for small purchases made by government institutions. This page provides information about the implementation, use and accounting treatment of procurement cards.
The procedures were developed by the Financial Management Authority (Fjársýslan) and the National Audit Office of Iceland.
Procurement cards are generally used for low-value purchases.Procurement cards must not be used for instalment payments. Instalment payments are considered credit transactions and require approval from the Ministry of Finance and Economic Affairs.
Cardholders are responsible for the use of their cards and must:
retain receipts, invoices and other supporting documents
submit documentation to the person responsible for invoice processing within the institution
obtain copies of lost receipts or invoices
As a matter of good practice, cardholders should sign a declaration acknowledging responsibility for the use of the procurement card.
Before introducing procurement cards, an institution should assess its operational needs.
The assessment should determine:
which transactions are suitable for procurement card use
which departments will use the card
which employees will be cardholders
the maximum transaction limit
Careful preparation helps ensure efficient and effective use of procurement cards.
Institutions must complete a transfer document and submit it to Fjársýslan.
The document must include:
project or account reference
transaction type
accounting code
national identification number
dimensions or accounting segments
description
The transfer document and supporting documentation must be sent to bokhald@fjs.is no later than the 8th day of each month.
Original supporting documents must be included.
Institutions must:
retain all receipts and documentation that itemise purchases
ensure that an invoice or receipt is available before recording an expense
obtain replacement copies if original documents are lost
Cardholders are responsible for all transactions and must submit supporting documents to the institution's procurement card administrator.
At the end of each month, the transaction statement must be reviewed and verified to ensure that a receipt or invoice exists for every transaction.
Procurement card transactions must be recorded through the institution's accounts payable account using:
type 2216
the card issuer's national identification number
Transactions are recorded in the accounting period in which the purchase was made.
Institutions must:
retain all receipts and documentation that itemise purchases
ensure that an invoice or receipt is available before recording an expense
obtain replacement copies if original documents are lost
Cardholders are responsible for all transactions and must submit supporting documents to the institution's procurement card administrator.
At the end of each month, transactions listed on the payment statement must be reviewed to verify that a receipt or invoice exists for every transaction.
Posting codes are used to identify and classify specific accounting transactions and budget authorisations. They are usually linked to a particular account type or transaction category.
Posting codes are used for, among other things:
tax-related and reportable payments
special VAT transactions
loan transactions
investment contributions (type 2320)
investments
share capital and foundation contributions
budget authorisations
Posting Codes
Code | Description |
|---|---|
91 | General Ledger (GL), automated entries |
92 | General Ledger (GL), automated entries |
95 | General Ledger (GL), manual entries |
96 | General Ledger (GL), manual entries |
98 | General Ledger (GL), automated entries for VAT on digital services |
0 | General, not reportable |
1 | Reportable payments to individuals other than payroll and contractor payments subject to withholding tax |
2 | Reportable contractor payments |
22 | Reportable contractor payments for work in progress |
3 | Employee pension contribution |
4 | Contribution to a private pension fund |
6 | Salaries and other payments subject to withholding tax but processed outside payroll withholding |
7 | Withholding tax deducted from salaries |
8 | Location allowance |
9 | Not reportable |
Identification Number Requirement
When a posting code is used for a reportable payment, the national identification number (ID number) of the person being reported must be included with the accounting entry.
If posting code 0 or 9 is used, no identification number is required.
Code | Description |
|---|---|
16 | Opening balance from previous year |
17 | New loans |
18 | Loan repayments |
19 | Revaluation |
Note:
Only the Financial Management Authority may use posting code 16
Posting code 19 is only used by the Treasury
Transactions may only be posted to type 2320 if a posting code and operating unit reference are included.
Code | Description |
|---|---|
15 | Adjusted balance from previous year |
16 | Transferred balance from previous year |
17 | Annual investment authorisation |
18 | Allocation of investment authorisation |
20 | Capital gain on sale |
21 | Investment gifts and donations |
Expense Accounts (5xxxx)
For predefined expense accounts that transfer balances to work in progress (account types 18011 and 18012):
Use posting code 22 when costs relate to work in progress.
An automated process transfers the balance and records it using posting code 23
Asset Accounts (18xxx)
For asset accounts in the range 181-189, posting code 0 is generally used.
If a transaction should not be transferred to the fixed asset system (FA), use posting code 9.
Code | Description |
|---|---|
16 | Opening balance from previous year |
17 | Purchases |
18 | Sales |
19 | Other changes, such as dividends and exchange rate differences |
Budget authorisation posting codes indicate the source or reason for the authorisation.
Budget Acts and Supplementary Budget Acts
Code | Description |
|---|---|
A1 | Budget Act |
A2 | Supplementary Budget Act |
A3 | Supplementary Budget Act 2 |
A4 | Supplementary Budget Act 3 |
A5 | Supplementary Budget Act 4 and 5 |
Code | Description |
|---|---|
AA | Transfer due to salary, exchange rate and price compensation |
AB | Transfer from the general contingency reserve |
AC | Transfer under an authorisation provision |
AD | Investments and depreciation |
AE | Authorisations for accelerated projects |
AF | Transfer from the Government's contingency allocation |
AH | Transfer between budget items |
AJ | Transfer within a budget item |
AL | Transfer between accounting periods |
AR | Carried forward from previous year |
AS | Adjustment relating to previous year |
Additional Information
Codes A1-A5 are used for budget authorisations approved by Parliament through the Budget Act or Supplementary Budget Acts.
Codes AA-AJ, except AD, are used for transfers of budget authorisations carried out by ministries.
Code AD is used for depreciation expenses and the allocation of investment authorisations.
Code AL is used when budget authorisations are distributed across accounting periods in accordance with the operating plan.
A typical accounting process for a government entity is as follows:
An invoice is received.
The invoice is reviewed.
The invoice is approved.
The cost is classified to the appropriate account, activity, and spending authority.
The transaction is recorded in the accounting system.
The invoice is paid.
The transaction becomes part of monthly reporting, the entity's annual financial statements, and ultimately the Financial Statements of the Central Government.
Institutions carrying out VAT-liable activities collect value added tax (VAT) on the sale of goods and services and pay the tax to the Treasury.
More information about VAT can be found on the Directorate of Internal Revenue website.
What are hospitality expenses?
Hospitality expenses are costs incurred by a government institution or office for the purpose of showing hospitality, appreciation, or recognition to guests, partners, or other recipients.
Conditions for hospitality expenses
The following conditions must be met before hospitality expenses can be incurred:
There must be a valid and justified purpose.
Budget authorization must be available.
Written approval must be obtained from the head of the institution or the relevant ministry.
Approval form
A hospitality approval form must be submitted when expenses are recorded as hospitality expenses.
An approval form is always required for purchases of alcoholic beverages.
The approval form is available on the Information Portal.
Submission of hospitality expense claims
When submitting hospitality expense claims, the following requirements apply:
Itemized receipt
The receipt must be clearly itemized and show the nature and extent of the expenses.
Approval by the head of institution
The receipt must be approved by the head of the institution. For higher-value hospitality expenses, government institutions must consult the relevant ministry.
Purpose and participants
The receipt or an accompanying document must include:
the purpose of the hospitality expense,
the justification for the expense,
the recipients of the hospitality,
whether consultation took place with the relevant ministry.
