Overview
The Entity on an accounts payable invoice identifies which legal entity within your organization the bill belongs to. It appears on the invoice header and, in some cases, on individual invoice lines. Because the entity determines which part of the business carries the cost, an incorrect value needs to be caught before the invoice is submitted.
Auditoria populates the Entity automatically while the invoice is being processed, so the field is usually filled in before you open it. The system checks several sources in a fixed priority order and uses the first one that returns a value. This article explains that order so you can understand why the entity on an invoice you are reviewing has the value it does. You can change the entity on any invoice, whichever source set it, and the system records the change.
Terms used in this article
Header entity and line-level entity. The header entity applies to the invoice as a whole. A line-level entity applies to an individual invoice line. Some sources set only the header entity, as noted in Table 1.
Vendor hints. A hint is an entity saved against a vendor by an administrator, used as a suggestion when no purchase order supplies a value. Hints apply to the header entity only.
How the Entity value is determined
The system checks each source in priority order and stops at the first one that returns an entity. Priorities 1 through 5 form that sequence, and every source in it is evaluated in turn until one returns a value. Business rules are not part of the sequence: they run after every source has been evaluated and can replace the value already assigned. Manual entry is the outcome when no source returns a value.
Table 1. Entity population order on AP invoices
| Priority | Source | How the value is set |
|---|---|---|
| 1 | Purchase order or supplier contract | If the invoice is matched to a purchase order or supplier contract, the entity from that record is used. This source has the highest priority. |
| 2 | Vendor hints | If no purchase order or supplier contract entity is available, the hint saved against the vendor assigns the entity. Sets the header entity only. |
| 3 | Entity Extraction & Matching | If neither of the above returns a value, the system reads content extracted from the invoice and matches it against valid entities. Sets the header entity only. |
| 4 | Default to Last Bill Entity | If Entity Extraction & Matching returns no value, the system copies the entity from the most recent bill for the same vendor. Sets the header entity only. [VERIFY: Confirm that Default to Last Bill Entity does not set a line-level entity.] |
| 5 | Predictive Coding | If no higher-priority source returns a value, the system predicts the entity from coding patterns on past invoices for the same vendor. This is the lowest-priority automated source. |
| After all sources | Business rules | Business rules run after all population methods and can override the entity already assigned. |
| If no value | Manual entry | If no source returns a value, the field stays blank for you to complete. |
Important: Business rules run last, and they run only during initial processing. Even when the entity came from a purchase order, a hint, or any automated source, a business rule can still replace it at that point. Business rules do not run again for any action taken afterwards, such as changing the vendor or removing a purchase order match.
Worked examples
The table below walks through what wins in each situation, reading Table 1 from the top each time.
Table 2. Which source supplies the Entity in common situations
| Source that supplies the Entity | What is true about the invoice |
|---|---|
| Purchase order or supplier contract | Matched to purchase order PO-4402. The vendor also has a hint entity saved. |
| Vendor hints | No purchase order match. The vendor has a hint entity saved. |
| Entity Extraction & Matching | No purchase order match and no hint. The invoice names the entity in its content. |
| Default to Last Bill Entity | No purchase order match, no hint, and the invoice does not name an entity. The vendor has billed before. |
| Predictive Coding | No purchase order match, no hint, no entity named on the invoice, and this is the first bill from the vendor. |
| Business rules | Any of the above, and a business rule matches the invoice. |
| No source. The field stays blank. | None of the sources returns a value. |
How the sequence runs end to end
The table above shows where each invoice stops. This example follows a single invoice through every step of the sequence.
An invoice arrives from Acme Corp for the first time. Acme has no purchase order on file and no hint entity saved.
The system checks priority 1 and finds no purchase order match, then priority 2 and finds no hint. At priority 3, Entity Extraction & Matching reads the invoice but finds no text that matches a valid entity. At priority 4, Default to Last Bill Entity has nothing to copy because this is Acme's first bill. At priority 5, Predictive Coding examines how invoices with similar characteristics have been coded and supplies an entity.
The invoice opens with the Entity populated. A business rule could still replace that value before you see it.
Conditions that change the outcome
Several conditions affect which source wins, or prevent a source from applying at all.
Vendors restricted to one entity. A vendor can be configured to permit a single entity, several entities, or any entity. When a vendor is restricted to one entity, that entity is populated automatically. When a vendor permits several entities or any entity, the order in Table 1 applies normally.
Line-level entity. Vendor hints and matching logic apply to the header entity only. Line-level entity can be populated through predictive coding or through purchase order and supplier contract updates.
Removing a purchase order match. If you remove a purchase order or supplier contract match from an invoice, the entity does not automatically revert to the vendor hint. Check the Entity field and correct it manually if the value is no longer right.
Changing the vendor. Changing the vendor does not rerun the population sequence. The entity already on the invoice is reassessed against the new vendor instead. If that entity is also valid for the new vendor, it is preserved. If it is not valid and the new vendor permits a single entity, that entity is populated. If it is not valid and the new vendor permits multiple entities, the field is left blank for you to complete. Business rules do not run again after a vendor change, so review the Entity field whenever you change the vendor.