The current setup does not provide an optimal connection between the Spend Cloud and the financial system, particularly concerning VAT registration. The purchase invoice is only sent to the financial system once it has been fully approved. This timing is too late. Depending on the capabilities of the financial system, two types of pre-registration can be utilized: with or without rules. Both types of registrations are explained below.

1. Pre-registration without invoice lines

When an invoice is coded and sent to an approver in the Spend Cloud, it can be pre-registered. The following entries will be made:

• Entry for the creditor
  
• Entry for VAT
  
• Temporary entry on an 'interim pre-registration account'
  
• The invoice is blocked for payment
  

If your organization wants to work with pre-registration, contact the Support department to enable this feature.

Booking Steps

Step 1

Immediately after the initial registration of a purchase invoice in the Spend Cloud, you must also record it in the financial system. This is necessary for recording the creditor, VAT, and costs on an 'interim pre-registration account'.

Journal Entry:

2xxxx Interim Pre-registration Account 100.00

1xxxx VAT 21.00

To 1xxxx Creditors 121.00

Step 2a -> Approved invoice:

After a purchase invoice is fully approved in the Spend Cloud, a final registration of costs against the 'interim pre-registration account' will be made. The invoice header will be resubmitted with only the document number and a different status, namely 'Approved'.

Journal Entry:

41xxx Cost X 50.00 (e.g., cost center 2000, period 11)

42xxx Cost Y 50.00 (e.g., cost center 3000, period 12)

To 2xxxx Interim Pre-registration Account 100.00

Step 2b -> Definitively disapproved invoice:

After a purchase invoice is definitively disapproved in the Spend Cloud, a complete reversal of Step 1 will be submitted.

Journal Entry:

1xxxx Creditors 121.00

To 2xxxx Interim Pre-registration Account 100.00

To 1xxxx VAT 21.00

Principles and requirements

1. After an invoice is sent in the Spend Cloud, the invoice header will be locked. No further changes can be made to the exported data from Step 1.
2. The export files from Steps 1, 2a, and 2b are submitted in this sequence and simultaneously in the 'Export' section (to prevent Steps 2a or 2b from being submitted before Step 1).
3. If an error is made in the invoice header, the invoice must be definitively rejected and re-added.
   
4. It is possible to change the coding of invoice lines if they are rejected in Spend Cloud; however, these changes are not exported or re-registered. If this is desired, you must permanently reject the invoice and add it again.
5. The export of "Costs in Transit" remains as it is. This is an accumulated posting of costs (sum of costs per ledger account-cost center combination) in journal form in period x (of all costs until period x+1 of invoices not yet exported through Steps 2a or 2b) with a contra entry on an 'in-transit costs account'. A complete reversal of the preceding entry is also immediately available for period x+1.

1. Go to the 'Invoice Processing' section > 'Export'.
2. At the top of the overview, there is a button labeled 'Export Pre-registration' to export pre-registrations per administration.
3. In the subsequent screen, the period can be adjusted if needed. Always choose 'Automatic Period Allocation: No' and then fill in the last open period under 'Adjust Period'. This ensures that all pre-registrations, potentially still assigned to a closed period (in the financial package), are updated to the selected open period.
   

4. You will now be taken to the 'Export Files' screen. A status bar will indicate the duration of the process.

5. In the meantime, you can leave this screen and even close your browser and computer. Exporting is a background process that continues at all times. Once completed, you will receive a report by email. You can also download the report in the 'Export Files' section.

Based on the general ledger account specified in the administration, it is determined which 'intermediary pre-registration account' will be booked. The 'intermediary pre-registration account' used will be the general ledger account specified in the administration for this type of expense:

6. Go to the Invoice Processing > Export section
   
7. At the top of the overview, you'll find the "Export Pre-registration" button to export pre-registrations for each administration.
   
8. In the following screen, you can optionally adjust the period. Always choose "Automatic Period Allocation: No" and then fill in the last open period under "Adjust Period." This ensures that all pre-registrations that might still be pre-registered in a period that has been closed within the financial system are updated to the selected open period.
   

9. You will now arrive at the "export files" screen. A status bar will indicate the duration.

10. Meanwhile, you can simply exit this screen and even close your browser and computer. Exporting is a background process that will continue at all times.
11. After completion, you will receive a report via email. Of course, you can also download the report in the 'export files' section.

It is possible to export multiple batches of invoices to the financial system at once, even when they are within the same administration. However, this is subject to the capabilities of the financial system. Additionally, it is theoretically possible that an approved invoice could be offered to the financial system before the invoice is pre-registered (because the pre-registration is in a batch that is not yet ready). In this case, the Spend Cloud will provide an error message, and the approved invoice will not be offered.

2. Pre-registration with invoice lines

1. Purchase invoices, after being initially fully coded and sent as final purchase journal entries in Spend Cloud Invoice Processing, are offered in the next export via the webservice. These are then blocked for payment.
2. Upon approval of the full invoice, the payment block will be lifted in the next export via the webservice.
3. After definitive rejection of an invoice, it will be fully reversed (using the coding known at that time) in the next export via the webservice.
4. Changes to an invoice that occur after initial full coding and sending will not be communicated in any form.