About matching A/P invoices and purchase orders manually

Related topics

In this routine, you manually match preliminary and final A/P invoices to purchase orders. Alternatively, you can set up the system to automatically match supplier invoice lines to purchase order lines. This is described in Setting up automatic invoice matching. For an illustration of the different system stages of both the manual and automatic invoice matching processes from a technical perspective, see A/P invoice automatic matching - Flowchart.

After the final matching, DC1 Financials will automatically create G/L postings for the differences. When you are matching preliminary invoices the G/L postings are stored in an interim file, Preliminary invoices G/L postings file. The analysis of the matching is done through listings which have been specifically designed for that purpose.

Note: The matching routine is linked to DC1 Distribution and therefore only applicable for purchase orders created within DC1. You must also be aware of the fact that purchase orders are linked to the matching routine after goods reception.


  • Only order lines with either status 42 (Ready for printing of quality control note) or 60 (All order lines on the order are ready) can be matched, i.e. the goods have been received, confirmed and quality reviewed (if required).
  • The order line must in addition to the above be entered with a purchase order type that updates the Goods reception transaction file (Add to rec trans in Work with purchase order types must be set to YES).
  • The matching routine must be activated in the A/P control file (Inv manual matching is set to YES).

You have the choice to match preliminary A/P invoices, as well as final A/P invoices.

Matching of preliminary invoices is a separate routine (Work with A/P preliminary invoices matching) that may be initiated at any time. Preliminary invoices can be matched repetitively and the invoice can eventually be matched one last time when making it final.

Matching of final invoices is part of the normal A/P invoice entry routine. Final invoices may be matched when entering invoices directly and when changing preliminary invoices into final.

The same panels appear when matching preliminary and final invoices. Also accounting postings are created equally. However, postings for preliminary invoices do not update the General Ledger but are stored in an interim file, Preliminary invoices G/L postings file, transparent to users, whereas postings are copied to the G/L transactions entry file when the preliminary invoice is made final.

Note: Should any goods reception transactions and A/P invoices be in a held status due to a disruption such as a communication line failure or power failure, those records can be unlocked by using the Unlock all goods reception lines routine.


The system handles automatic creation of quantity, price and exchange rate differences. All three different kinds of variances can occur on the same invoice and the system can thus calculate a combination of these three postings.

Note: Variance postings will only be created if you do manual changes (other than exchange rate differences) for the value of the order lines.

Quantity difference

A quantity difference will be posted if the invoiced quantity differs from the used (received) quantity. Quantity differences can only be positive since invoiced quantity may not be greater than used quantity. Quantity differences are calculated as an amount and no quantity transactions are created in combination with the amount postings. Quantity differences (transaction type 812) are calculated as follows:

Quantity difference = (invoiced quantity - used quantity) x invoiced price

Price difference

A price difference will be posted if the invoiced price has changed since the order was placed. Price differences (transaction type 813) are calculated as follows:

Price difference = (invoiced price - order price) x used quantity

Exchange rate differences

An exchange rate difference will be posted if the exchange rate has been changed since the order was placed. The same currency must be used on both the order and invoice if the system is to create an exchange rate difference posting (transaction type 811). Exchange rate differences are posted in the system currency only, which means that transaction type 811 will show a blank posting in the transaction currency.

Exchange rate differences (transaction type 811) are calculated as follows:

Exchange rate difference = (Total invoiced + quantity differences + price differences) - (Total received from supplier)

For more information about the accounting, which is partially controlled by the transaction types in DC1 Distribution, see Overview of accounting transactions during supplier invoice matching.


When the invoice is received, but the goods have not yet arrived, the goods are in-transit. The invoiced amount of the goods that have not yet arrived can be booked on a pre-defined goods-in-transit account (pseudo account XGIT). The invoice can be re-matched at a later stage even if it has already been paid.

Residual unmatched amounts can be booked on a goods-in-transit account when entering and matching final A/P invoices. Subsequently, those invoices can be re-matched and re-accounted an infinite number of times, until the goods-in-transit balance reaches zero.

Sometimes it happens that the missing goods do not arrive. In that case it is possible to use the same Work with A/P goods-in-transit routine to re-account the invoice by transferring the GIT amount to an appropriate cost account.

Adjustment of rounding difference in system currency

If the total of the reversal of goods received not invoiced (GRNI) accruals ends up with a rounding difference in system currency compared to the amount of the invoice in system currency, this rounding difference is adjusted using pseudo account XROUND. The adjustment takes place if no cost accountings exist for the invoice other than transaction types 930, 810 and 814 (VAT and control account excluded).

If pseudo account XROUND is not defined, which is done in the Pseudo account file, and if no transactions exist on the invoice, the system will check in the following order which transaction type will be adjusted:

Manual matching If a normal purchase order If a project purchase order























The G/L postings from the matching routine are created automatically by accounting through transaction types as defined in DC1 Distribution. For more information, see Overview of accounting transactions during supplier invoice matching.

The transaction types used in the manual matching routine are:



Exchange rate difference


Quantity difference


Price difference


Invoiced purchases


Goods received, not yet invoiced


Return to supplier


Landed cost


Note: In the automatic matching, price differences are booked using transaction type 809. See About working with automatic invoice matching.

All these transaction types are connected to trade accounts with the exception of 930, 931 and 932 (these are balance accounts of the same type as supplier control accounts). Transaction type 930 is used when matching an invoice and 931 is used when matching a credit note. Transaction type 810 is debited and transaction type 814 is credited for a reception from supplier and these transactions create a double posting of the purchase value. These postings can be used for statistical VAT purposes. If they are not needed, 810 and 814 can be linked to the same account in DC1 Financials, and if this account is summarised a posting that will create a zero balance will be made, instead of one credit and one debit with the same amount.

Note: If pre-accounting information is defined on the purchase order line in DC1 Distribution, transaction type 810 will be exchanged with the actual account(s) defined on the order line. This means that if the pre-accounting function is used in DC1 Distribution, then the transaction types 810 and 814 cannot be linked to the same accounts in DC1 Financials to create a zero balance. For more information about pre-accounting, see About pre-accounting purchase orders.

When matching preliminary invoices, the G/L postings are stored in an interim file called Preliminary invoices G/L postings file. The General Ledger itself is not updated. Postings in this interim file are copied to the G/L transactions entry file when the preliminary invoice is made final.

All postings automatically created during the matching will be shown on the G/L entry panel for final invoice postings when you have updated the matching, but they cannot be maintained. If there are errors you will have to cancel the entire invoice and start all over again. The postings that are made to the G/L are only amount postings, no quantities are ever posted.

VAT calculations are postings that are handled differently in the matching routine depending on how the VAT is entered in the system.

If VAT is entered on invoice level, VAT will be created before matching, and only net amounts will be posted in the matching routine.

If VAT is entered on G/L level, the matching routine will automatically generate VAT postings from the VAT handling code entered during the matching process. The VAT handling code must be valid for the account represented by transaction type 810. The VAT calculation and postings will be based on the definitions in the VAT handling code table.

If the supplier is exempt from VAT, as defined in the Business partner file, then the system will override the VAT handling code of the product with the default VAT free code from the DIS control file.

Enquiries and printouts

  • Purchase order matching enquiry
  • A/P invoice matching enquiry
  • Supplier invoice matching reconciliation list
  • Goods-in-transit file listing
  • Supplier invoice variance analysis list (DC1 Distribution)
  • Supplier invoice variance analysis list (DC1 Financials)
  • Matching tolerance limits table list

Related topics