[et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row column_structure=”1_2,1_2″ _builder_version=”4.17.6″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”1_2″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.9″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n
What does your invoice verification process miss<\/strong> if it only compares the invoice total to the purchase order total? Perhaps you recognize this approach: if the purchase order number exists and the total matches, the invoice is approved, and the line items below are not reviewed further. Checking only the total allows discrepancies to slip through that cancel each other out in the total: the total is correct, but the line items aren\u2019t. If you check the total, you know the sum is correct\u2014not that the invoice itself is correct. Your approach wasn\u2019t negligence. <\/p>\n This page about 3-way invoice matching<\/strong> shows you what you can check in your own settings tomorrow: header or line-item level, how many documents you\u2019re matching an invoice against, and what your tolerances are set to. A structured e-invoice delivers the invoice data in a structured format, but does not automatically compare it to a purchase order or receipt. That matching process remains a separate step. You can read more about this in the section on what structured invoices do and don\u2019t solve<\/a>. First, let\u2019s look at the other side: what can you determine about matching at the total level? <\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=”1_2″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/juvo.be\/wp-content\/uploads\/juvo-factuurmatching-regelniveau-hero.webp” alt=”Invoice and purchase order side by side, with one matching line highlighted in violet on each document.” title_text=”juvo-factuurmatching-regelniveau-hero” _builder_version=”4.27.9″ _module_preset=”default” border_radii=”on|6px|6px|6px|6px” global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” background_color=”RGBA(255,255,255,0)” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row make_equal=”on” _builder_version=”4.17.6″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text admin_label=”Tekst” _builder_version=”4.27.9″ _module_preset=”default” background_color=”#F2F2F2″ min_height=”100%” custom_padding=”25px|25px|25px|25px|true|true” border_radii=”on|6px|6px|6px|6px” global_colors_info=”{}”]<\/p>\n In the AP environments we encounter<\/strong>, many tools and ERP systems match the invoice total against the purchase order total rather than line by line. Matching by total is quicker to set up. It usually works in the ERPs we encounter without any customization. And for an invoice with no line-item discrepancies, matching by total yields the same result as matching at the line-item level. These are isolated observations, not an explanation of how organizations configure their matching processes. <\/p>\n What does that mean for you?<\/strong> Your setting was not negligence. The difference with line level only arises with an invoice where line items differ. Matching at the total is a design choice with a consequence: differences that cancel each other out go unnoticed. What happens now with an invoice where the line items do differ? <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row admin_label=”Row” _builder_version=”4.17.6″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n <\/p>\n Take, for example<\/strong>\u2014and not as a customer case\u2014an invoice and a purchase order totaling \u20ac10,000. Line 1 is overbilled by \u20ac500, line 2 is underbilled by \u20ac500, and line 3 is correct. The difference in the total is \u20ac0. <\/p>\n <\/p>\n <\/p>\n Checking the total allows for discrepancies that cancel each other out in the total<\/strong>: in this example, the total is correct, but the line items are not. If you check the invoice at the line-item level, you\u2019ll see line 1 and line 2 listed next to their corresponding purchase order lines. The example does not indicate how often this happens. <\/p>\n In the AP environments we\u2019re seeing,<\/strong> discrepancies at the line-item level\u2014such as incorrect items, price agreements that weren\u2019t followed on a single line item, and overbilling hidden behind a partial shipment\u2014cancel each other out overall. In the case of an incorrect item, the invoice line item lists something different from what you ordered. In the case of a price agreement that wasn\u2019t followed, the price on that specific line item differs from what was agreed upon. In the case of over-invoicing hidden behind a partial delivery, a line item is invoiced for more than was actually delivered. So, what do you use to verify an invoice line item: just the purchase order, or also the delivery receipt and inspection report?[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row admin_label=”Row” _builder_version=”4.27.7″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.9″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n The number of documents you attach to an invoice depends on the nature of the purchase,<\/strong> not on a single, blanket setting. With a software license, there is no physical receipt of goods. Below, you can see for each level which purchases this applies to and what it covers. <\/p>\n <\/p>\n <\/p>\n 2-way matching compares the invoice with the purchase order<\/strong>. It is suitable for purchases without a physical receipt, such as services, subscriptions, licenses, and framework agreements. In such cases, there is no receipt to compare the invoice against. <\/p>\n Detects<\/strong>: differences in price and, depending on your system, also in quantity compared to the order.<\/p>\n <\/p>\n <\/p>\n 3-way matching includes the receipt of goods<\/strong>. It applies to goods. For an SME that purchases goods, 3-way matching is the basic check on those purchases: you verify that you are paying for what was ordered and received. This is a practical consideration for an SME that purchases goods. <\/p>\n Includes<\/strong>: in addition, billing for items that were not (fully) received.<\/p>\n <\/p>\n <\/p>\n 4-way matching adds the inspection step<\/strong>. It is used in situations where inspection is critical, such as manufacturing, pharmaceuticals, food, and construction. These sectors are just a few examples. In such situations, a delivery that has arrived has not yet been approved. <\/p>\n Includes<\/strong>: in addition, payment for goods that were received but rejected.<\/p>\n However, you can only<\/strong> compare line by line once you know which invoice line corresponds to which purchase order line.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row admin_label=”Row” _builder_version=”4.17.6″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.9″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n That\u2019s the problem<\/strong>: matching at the line level won\u2019t work if the supplier uses a different description than the buyer. That\u2019s true for exact-text matching. The supplier\u2019s description isn\u2019t necessarily the same as the buyer\u2019s. In that case, exact-text matching won\u2019t work. <\/p>\n Here\u2019s an example: the purchase order says \u201cA4 copy paper, 80 g\/m\u00b2,\u201d and the invoice says \u201cWhite A4 paper, 80 g, 500 sheets.\u201d In this example, both refer to the same item: 80-gram A4 paper. If you want to match an invoice with a purchase order and a receipt, a letter-by-letter comparison won\u2019t help you here. To match at the line level, link invoice lines to purchase order lines based on meaning<\/strong> rather than exact text. If something isn\u2019t listed on the purchase order, note it\u2014don\u2019t force it into a line. <\/p>\n For those managing the application: linking and comparing are two separate steps<\/strong>: first, you link each invoice line to a purchase order line; then, you compare the quantity and price for each pair. In our experience, AI is needed for the semantic linking, but not for the rest of the matching process. We do not specify a match percentage here. You can read more about our approach under \u201cProcess Automation at JUVO<\/a>.\u201d When is a discrepancy between two linked lines significant enough to block the invoice?[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.20.4″ _module_preset=”default” custom_padding=”0px||0px||true|false” locked=”off” global_colors_info=”{}”][et_pb_row admin_label=”Row” _builder_version=”4.17.6″ _module_preset=”default” width=”100%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.6″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.9″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n That\u2019s what the tolerance determines: it defines which discrepancy between linked rules constitutes an exception. If your purchases vary in amount or type, a single overall tolerance will be too broad for some categories and too strict for others. Four principles apply to your invoice verification tolerances<\/strong>. <\/p>\n 1. Percentage and absolute limit.<\/strong> A tolerance should have both a percentage and an absolute limit. Here\u2019s a calculation example without an absolute limit: a 2% tolerance on an order of \u20ac1,000,000 allows for a difference of \u20ac20,000. <\/p>\nWhat actually works well in terms of overall matching<\/h2>\n
What Goes Unnoticed<\/h2>\n
\n\n
\n Rule<\/strong><\/td>\n Invoice<\/strong><\/td>\n Order Form<\/strong><\/td>\n Difference<\/strong><\/td>\n<\/tr>\n \n Rule 1<\/td>\n \u20ac4,500<\/td>\n \u20ac400<\/td>\n + \u20ac500<\/td>\n<\/tr>\n \n Rule 2<\/td>\n \u20ac3,000<\/td>\n \u20ac3,500<\/td>\n – \u20ac500<\/td>\n<\/tr>\n \n Rule 3<\/td>\n \u20ac2,500<\/td>\n \u20ac2,500<\/td>\n \u20ac 0<\/td>\n<\/tr>\n \n Total<\/td>\n \u20ac10,000<\/td>\n \u20ac10,000<\/td>\n \u20ac 0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Matching two, three, or four times: what to check and where<\/h2>\n
2-way matching: invoice vs. purchase order<\/h3>\n
3-way matching: including the receiver<\/h3>\n
4-way matching: when the evaluation counts<\/h3>\n
Rule Link: The supplier does not use your words<\/h2>\n
Tolerances: Where the Hidden Profit Lies<\/h2>\n