The Validation view

Performs a checksum validation of Swedish bankgiro account numbers. The validation is performed on the SupplierAccountNumber2 field.

The validation rule is available for Swedish document types.

Performs length, identifier and checksum validations on the PaymentReferenceNumber field to ensure the validity of creditor reference numbers.

This validation is currently only available for Swiss document types and requires the PaymentReferenceNumber field.

Validates the due date field (InvoiceDueDate).

This validation makes sure that the date:

• occurs on or after today’s date.
• does not occur too far in the future.
• is a valid date. Note that English date formats are valid on all document types, including non-English document types.

Due-date limit (days) - Due dates are only valid if they do not exceed the current date plus the number of days you specify here.

Calculate due date from payment-terms master data - Uses payment terms master data to validate and optionally supply the due date.

Warns if invoices with the same supplier number, invoice number, invoice date or invoice amount exist during verification or workflow processes. This can prevent duplicate invoices caused by:

• the supplier resending the same invoice by mistake or on purpose.
• the same invoice being scanned more than once.
• scanning software errors.
• an error in AP Essentials.
• original invoice attachments that are not recognized as an attachments and treated as separate invoices.

AP Essentials checks for duplicates:

• After document extraction.

• During verification.

• During approval.

  • During document registration and post.

• During export.

If a duplicate invoice is detected during verification or approval, the validation error is set on all relevant fields. For example, if Include invoice date and Include invoice amount are selected, and a duplicate invoice is detected, then the validation error is set on the invoice number, invoice date and invoice amount fields.

All relevant fields necessary for the duplicate invoice check are required. For example, if Include invoice date and Include invoice amount are selected, then invoice number, invoice date and invoice amount are all required in the document type. If any field is missing, the duplicate check will not execute.

The supplier number and invoice number are always checked when performing this validation, however, Include invoice date and Include invoice amount checks are optional and can be toggled in the Duplicate invoice check setting. If Include invoice date and Include invoice amount are selected, the invoice number, invoice date and invoice amount must all be the same as a previously processed invoice in order to be considered a duplicate. If you select Include invoice amount, the total amount field is used. However, if the total amount field is missing from the document type, the net amount field is used.

If a user overrides this validation, it is noted in the document history.

This validation relies on data collection that is only gathered when this validation is enabled. Therefore, duplicate invoices are not validated against invoices that were processed prior to enabling this validation.

The duplicate invoice check is performed per buyer, so it is possible to have invoices with the same invoice number, for example, if they are for different buyers.

Duplicate-invoice information is saved for each invoice in a registry when:

• The invoice is verified.

• The invoice is changed in a workflow, for example, if you add a coding line or change a field value.

• The invoice is sent to the target system.

Therefore, if you use Workflow services and bypass verification via the data verification settings, the validation might not detect duplicate invoices until post in some circumstances.

Ensures that invoiced quantities match the quantities of goods received (3-way matching) by performing two checks:

• The quantity on the invoice must be equal to or less than the delivered quantity of the goods received on the purchase order:

  invoice quantity ≤ PO goods received quantity

• The quantity on the invoice must be equal to or less than the delivered quantity of the goods received on the purchase order minus the invoiced quantity on purchase order:

  invoice quantity ≤ (PO goods received quantity - PO invoiced quantity)

Invoices that fail this validation are automatically put on hold.

Automatic retry (days) - specifies the number of days AP Essentials will continue to automatically check the goods received quantity before sending the invoice to the next step. Automatic retry is only triggered if you override this validation during verification or approval and approve the invoice. Checks will be made automatically and continuously until the document passes validation or until the number of days you specify here passes, whichever comes first. If you change this setting, the new value is applied to invoices that are already on

Performs a checksum validation (ISO 7064) to ensure IBAN numbers are valid. The validation is performed on the SupplierIBAN1, SupplierIBAN2, SupplierIBAN3 and SupplierIBAN4 fields.

If the document type contains multiple IBAN fields, all of the IBAN fields are validated.

Validates the invoice date field (InvoiceDate).

This validation makes sure that the date.

• occurs before or equal to today’s date.
• does not occur too far in the past.
• is a valid date.

Invoice-date limit (days) - Invoice dates are only valid if they are not older than the current date, minus the number of days you specify here.

Process limit (days) - Invoices are stopped if the invoice date is older than the current date minus the number of days you specify here. Unlike Invoice-date limit, you cannot override this validation error by pressing Enter during verification. The value you specify here must be greater than Invoice-date limit unless you specify 0 to disable this setting (default value: 0).

Makes sure line items are specified on documents. If no line items are found during extraction, or if all line items are missing or removed during verification or approval, the validation fails and a warning message is displayed. The validation error is set on the total amount field, and you cannot override this validation error. In other words, you cannot process the document further without line items.

Validates each line-item row to ensure that the amounts add up to the row total. If no line-item rows are found on the document, the validation is not performed. This validation handles amounts up to 5 decimal places.

The validation checks if the calculated row total and the captured row total match within an acceptable margin of error. The validation calculates the row total by multiplying the delivered quantity by the unit price and applying any discounts. Then the calculated row total and the captured row total are compared using a margin of error. If the amounts exceed the margin of error, the validation fails.

Discounts

When performing the calculations, the validation considers discounts (percentage discounts and amount discounts) on the row total and the unit price in this order:

1. The discount is applied to the total amount.

   LIT_VatExcludedAmount = (LIT_DeliveredQuantity * LIT_UnitPriceAmount) * (1 - LIT_DiscountPercent) – | LIT_DiscountAmount|

2. The discount is applied to the unit price.

   LIT_VatExcludedAmount = LIT_DeliveredQuantity * (LIT_UnitPriceAmount * (1 - LIT_DiscountPercent) – |LIT_DiscountAmount|

Note that the absolute value of the discount amount is used. Fields in bold must be selected (enabled) in the Document type view in order for the validation to work properly. The discount fields are optional.

Ensures that the total amount of the invoice matches the total sum of all line-item rows when verifying line items.

The validation compares the sum of the amount fields and the total sum of all line-item rows with the total amount.

InvoiceTotalVATIncludedAmount = SumOfTotalNetAmountFromLineItems + InvoiceTotalVATAmount + DeliveryCost + DeliveryCostPackaging + DeliveryCostInsurance + DeliveryCostToll + DeliveryCostPostage - InvoiceDiscountAmount

For remittance advices, see the Line-item total amount validation in the Accounts receivable validations section below.

This validation can help prevent documents with high amounts from passing through the system unnoticed.

• Maximum total amount limit - Makes sure the absolute value of the total amount field (InvoiceTotalVATIncludedAmount) does not exceed the value you specify here. If you do not use the total amount field, the net amount field (InvoiceTotalVATExcludedAmount) is checked instead.

  If the absolute value total amount is greater than the value you specify here, the field is marked with a warning icon, but you can override the validation.

• Process limit (amount) - This validation works the same as the Maximum total amount limit, however, you cannot override the Process limit. Therefore, if you receive an invoice that exceeds the process limit, you must increase the value of this setting to continue, or delete the document.

Performs a checksum validation for OCR numbers on Swedish invoices. The validation is performed on the PaymentReferenceNumber field.

You can only enable this validation for Swedish document types.

Performs a checksum validation for organization numbers on Swedish invoices. The validation is performed on the SupplierTaxNumber1 field.

You can only enable this validation for Swedish document types.

Validates various payment fields, depending on the payment type. You can only use this validation for Danish, Norwegian and Swedish document types.

Default cash-account number - The default cash account to use when you specify Entry only as the payment type.

See also:

• Processing Danish invoices with E-conomic.
• Processing Norwegian invoices with E-conomic
• Processing Swedish invoices with E-conomic
  If you use this validation, you must select Verify and Workflow.

Validates Swedish plusgiro account numbers. The validation is performed on the SupplierAccountNumber1 field.

You can only enable this validation for Swedish document types.

Ensures that the invoiced quantities match the quantities on the purchase order (2-way matching) by performing two checks:

• Quantities on the invoice must be equal to or less than the quantities on the purchase order.

  invoice quantity ≤ PO quantity

• The quantity on the invoice must be equal to or less than the purchase order quantity minus the invoiced quantity on purchase order.

  invoice quantity ≤ (PO quantity - PO invoiced quantity)

Purchase order over-quantity tolerance (percent) - Determines how much the quantity on the invoice can exceed the purchase order quantity.

For example, assume you type 10 in this setting to allow a tolerance of 10%. You have a purchase order with a line-item quantity of 20 items. The matching invoice line, however, has a quantity of 22. Because 20 plus 10% is 22, the quantity is within the tolerance and passes validation. If the matching invoice line had a quantity of 23, it would exceed the 10% tolerance and fail validation.

Ensures that the invoiced unit prices match the unit prices on the purchase order (2-way matching).

The unit prices on the invoice must be equal to or less than the unit prices on the purchase order to pass this validation.

invoice unit price ≤ PO unit price

Purchase order over-price tolerance (percent) - Determines how much the price on the invoice can exceed the purchase order price.

For example, assume you type 10 in this setting to allow a tolerance of 10%. You have a purchase order with a line-item price of $20. The matching invoice line, however, has a price of $22. Because 20 plus 10% is 22, the price is within the tolerance and passes validation. If the matching invoice line had a price of $23, it would exceed the 10% tolerance and fail validation.

Ensures that the total amount matches the total sum of all line-item rows when verifying line items on remittance advices. In other words, InvoiceTotalVATIncludedAmount must equal the sum of all LI_InvoiceTotal fields.

Maximum difference allowed - Specifies the margin of error (plus or minus) that is permitted when comparing sum of the line-item amounts with the total amount of the remittance advice.

Example: If you specify 0.5 here and the total amount on the remittance advice is 23.00, the validation will pass if the sum of the line-item total amount fields is anywhere between 22.50 and 23.50.

Applies default tax codes to header and line-item fields. The validation is performed on the TaxCode and LIT_TaxCode fields.

Makes sure the fields are formatted according to document type field format and that required field values are specified. The validation requires that all of the fields from at least one of these field groups are specified:

• IBAN (SupplierIBAN1)
• ESR Ref (EsrReference), ESR No (EsrNumber) and ESR Amount (EsrAmount)
• PC Account (SupplierPcAccountNumber), BLZ (SupplierBankCodeNumber1), BICSwift (SupplierBicSwiftNumber) and Bank account (SupplierAccountNumber1)

Checks the validity of QR references found in QR-IBAN numbers.

First, the validation checks positions 4 through 9 of the IBAN, using a zero-based index. If the value of positions 4 through 9 is within the range, 30000 - 31900, and the QR reference is exactly 27 characters long, the validation verifies the checksum of the reference field.

Ensures that the amount fields add up to the total amount field on the invoice. See how .

Net amount sum = InvoiceTotalVATExcludedAmount + DeliveryCost + DeliveryCostPackaging + DeliveryCostInsurance + DeliveryCostToll + DeliveryCostPostage - InvoiceDiscountAmount

Total amount sum = Net amount sum + InvoiceTotalVATAmount - WithholdingTaxAmount - WithholdingTaxAmount2

This validation handles amounts up to 5 decimal places and supports a margin of error that you specify in the Maximum difference allowed setting.

To pass the validation, the absolute value of Total amount sum minus InvoiceTotalVATIncludedAmount cannot be greater than Maximum difference allowed

ABS(Total amount sum - InvoiceTotalVATIncludedAmount) > MaximumDifferenceAllowed

Maximum difference allowed

Specifies the margin of error (plus or minus) that is permitted when comparing the total amount field with the calculated total amount.

Example: If you specify 0.5 here and the total amount on the invoice is 23.00, the validation will pass if the calculated total amount is anywhere between 22.50 and 23.50.

This validation ensures that the sum of all sub-tax fields equals the value of the total tax field.

InvoiceTotalVatAmount = InvoiceTaxAmount1 + InvoiceTaxAmount2 + InvoiceTaxAmount3 + InvoiceTaxAmount4

At least one of these fields must be selected (enabled) in the Document type dialog in order for the validation to work properly:

• InvoiceTaxAmount1
• InvoiceTaxAmount2
• InvoiceTaxAmount3
• InvoiceTaxAmount4

Maximum difference allowed - Specifies the margin of error (plus or minus) that is permitted when comparing the total tax field with the sum of the other tax fields.

Example: If you specify 0.5 here and the total tax on the invoice is 23.00, the validation will pass if the sum of the other tax fields is anywhere between 22.50 and 23.50.

Ensures that the VAT rate is one of the rates specified in the Allowed VAT rates box. Use semicolons (;) to separate valid VAT rates. You can write the VAT rates using any standard method of writing a percentage. For example, if you want to allow rates of 0%, 12.5% and 25%, you can type the following values in the Allowed VAT rates box:

0.0;12.5;25.0

This validation handles amounts up to 5 decimal places. The margin of error between the captured rate and the calculated rate cannot exceed 0.005.

This validation uses these fields:

• InvoiceNetAmount1, InvoiceTaxAmount1, InvoiceTaxRate1

• InvoiceNetAmount2, InvoiceTaxAmount2, InvoiceTaxRate2

• InvoiceNetAmount3, InvoiceTaxAmount3, InvoiceTaxRate3

• InvoiceNetAmount4, InvoiceTaxAmount4, InvoiceTaxRate4

  ...and so on, for each VAT rate.

In addition to the validations listed above, this rule also makes sure InvoiceTotalVatRatePercent matches one of the specified rates.

Validates delivery date fields of a purchase order.

This validation makes sure that the date:

• occurs on or after today’s date.
• does not occur too far in the future.
• is a valid date.

Also, if PO_DeliveryDate2 is enabled, the validation makes sure PO_DeliveryDate2 occurs after PO_DeliveryDate1.

Delivery-date limit (days) - Delivery dates are only valid if they are not older than the current date plus the number of days you specify here.

These fields are validated by this rule if enabled:

• PO_DeliveryDate1

• PO_DeliveryDate2

• LIT_PO_DeliveryDate

If the delivery date is not always known, consider enabling Accept empty value on the fields above to avoid validation errors.

Warns if purchase orders with the same customer number, purchase order number, purchase order date or purchase order amount exist during verification. This can prevent duplicate purchase orders caused by:

• the customer resending the same purchase order by mistake or on purpose.
• the same purchase order being scanned more than once.
• scanning software errors.
• an error in AP Essentials.
• original purchase order attachments that are not recognized as an attachments and treated as separate purchase orders.

AP Essentials checks for duplicates:

• After document extraction.

• During verification.

• During export.

If a duplicate purchase order is detected during verification, the validation error is set on all relevant fields. For example, if Include purchase order date and Include purchase order amount are selected, and a duplicate purchase order is detected, then the validation error is set on the purchase order number, purchase order date and purchase order amount fields.

All relevant fields necessary for the duplicate purchase order check are required. For example, if Include purchase order date and Include purchase order amount are selected, then purchase order number, purchase order date and purchase order amount are all required in the document type. If any field is missing, the duplicate check will not execute.

The customer number and purchase order number are always checked when performing this validation, however, Include purchase order date and Include purchase order amount checks are optional and can be toggled in the Duplicate purchase order check setting. If Include purchase order date and Include purchase order amount are selected, the purchase order number, purchase order date and purchase order amount must all be the same as a previously processed purchase order in order to be considered a duplicate. If you select Include purchase order amount, the total amount field (PO_TotalTaxIncludedAmount) is used. However, if the total amount field is empty or missing from the document type, the net amount field (PO_TotalTaxExcludedAmountvalue) is used.

If a user overrides this validation, it is noted in the document history.

This validation relies on data collection that is only gathered when this validation is enabled. Therefore, duplicate purchase orders are not validated against purchase orders that were processed prior to enabling this validation.

The duplicate purchase order check is performed per seller, so it is possible to have purchase orders with the same purchase order number, for example, if they are for different sellers.

Duplicate-purchase order information is saved for each purchase order in a registry when:

• The purchase order is verified.

• The purchase order is sent to the target system.

Makes sure line items are specified on documents. If no line items are found during extraction, or if all line items are missing or removed during verification, the validation fails and a warning message is displayed. The validation error is set on the total amount field, and you cannot override this validation error. In other words, you cannot process the document further without line items.

Validates each line-item row to ensure that the amounts add up to the row total. If no line-item rows are found on the document, the validation is not performed. This validation handles amounts up to 5 decimal places.

The validation checks if the calculated row total and the captured row total match within an acceptable margin of error. The validation calculates the row total by multiplying the quantity by the unit price. Then the calculated row total and the captured row total are compared using a margin of error. If the amounts exceed the margin of error, the validation fails.

This validation requires these fields:

• LIT_PO_OrderedQuantity

• LIT_PO_UnitPriceAmount

• LIT_PO_TaxExcludedAmount

Ensures that the sum of the line-item amounts adds up to the total amount of the remittance advice.

The validation compares the sum of the line-item amount fields (LIT_RA_AmountPaid) with the total amount field (RA_TotalAmountPaid).

Maximum difference allowed - Specifies the margin of error (plus or minus) that is permitted when comparing sum of the line-item amounts with the total amount of the remittance advice.

Example: If you specify 0.5 here and the total amount on the remittance advice is 23.00, the validation will pass if the sum of the line-item total amount fields is anywhere between 22.50 and 23.50.

For purchase orders, see the Line-item total amount validation below.

For invoices, see the Line-item total amount validation in the Accounts payable validations section above.

Ensures that the sum of the line-item amounts adds up to the total amount of the purchase order.

The validation compares the sum of the line-item amount fields ( LIT_PO_TaxExcludedAmount) and tax amount field (PO_TotalTaxAmount) with the total amount field (PO_TotalTaxIncludedAmount). If PO_TotalTaxIncludedAmount is not enabled, PO_TotalTaxExcludedAmount is used instead.

Note: Charge and discount fields are excluded from the calculation.

For remittance advices, see the Line-item total amount validation above.

For invoices, see the Line-item total amount validation in the Accounts payable validations section above.

This validation can help prevent documents with high amounts from passing through the system unnoticed.

• Maximum total amount limit - Makes sure that the total amount field (PO_TotalTaxIncludedAmount) does not exceed the value you specify here. If you do not use the total amount field, the net amount field (PO_TotalTaxExcludedAmount) is checked instead.

  If the total amount is greater than the value you specify here, the field is marked with a warning icon, but you can override the validation.

• Process limit (amount) - This validation works like the Maximum total amount limit, however, you cannot override the validation. Therefore, if you receive an invoice that exceeds the process limit, you must increase the value of this setting to continue, or delete the document.

Validates the order date field (OrderDate) of a purchase order.

This validation makes sure that the date:

• occurs before or equal to today’s date.
• does not occur too far in the past.
• is a valid date.

Order-date limit (days) - Order dates are only valid if they are not older than the current date minus the number of days you specify here.

Process limit (days) - The validation fails and cannot be overridden if the order date is older than the current date minus the number of days you specify here. Unlike Order-date limit, you cannot override this validation error by pressing Enter during verification. The value you specify here must be greater than Order-date limit unless you specify 0 to disable this setting (default value: 0).

Ensures that the total amount field equals the sum of the net value and tax amount fields of a purchase order.

PO_TotalTaxIncludedAmount = PO_TotalTaxExcludedAmount + PO_TotalTaxAmount

If any of the fields above are disabled or missing from the document type, the validation is not performed.

Note: Charge and discount fields are excluded from the calculation.

This validation handles amounts up to 5 decimal places and supports a margin of error that you specify in the Maximum difference allowed setting.

To pass the validation, the absolute value of the total amount minus the sum of the net value and tax amount fields cannot be greater than Maximum difference allowed

ABS(PO_TotalTaxIncludedAmount - (PO_TotalTaxExcludedAmount + PO_TotalTaxAmount)) <= MaximumDifferenceAllowed

Maximum difference allowed - Specifies the margin of error (plus or minus) that is permitted when comparing the total amount field with the calculated total amount.

Example: If you specify 0.5 here and the total amount on the purchase order is 23.00, the validation will pass if the calculated total amount is anywhere between 22.50 and 23.50.