# LLM Context
URL: https://alkemist.app/approvazione-delle-fatture-passive-workflow-controlli-e-gestione-delle-anomalie/

# Accounts Payable Invoice Approval: Workflows, Controls, and Exception Management

> A practical guide for small and medium-sized enterprises on designing an accounts payable invoice approval workflow that connects invoices, purchase orders, deliveries, operational responsibilities, controls, exceptions, and payment authorization.

**Image alt text:** Accounts payable invoice approval workflow with controls, exception management, and payment.

**Publication date:** July 12, 2026

Accounts payable invoice approval is often treated as the final step of an administrative process. In reality, it is where problems created earlier in the purchasing process become visible.

These problems may include:

* incomplete purchase orders;
* unconfirmed deliveries;
* terms that differ from those originally agreed;
* unclear cost centres;
* missing operational references;
* responsibilities left to individual memory;
* payment information that has not been properly verified.

An effective workflow must do more than collect a signature or approval.

It must make it possible to verify why an invoice can be:

* recorded;
* approved;
* disputed;
* blocked;
* returned for correction;
* authorised for payment.

For a small or medium-sized enterprise, the objective is not to add more approval steps. The objective is to distinguish straightforward cases from exceptions, make controls explicit, and reduce the time spent requesting confirmations from different people.

An effective accounts payable invoice approval workflow should connect the administration team, the requesting department, operational staff, purchasing personnel, and management where necessary.

## Contents

* [What must be approved](#what-must-be-approved)
* [Roles in the process](#roles-in-the-process)
* [Essential controls](#essential-controls)
* [Exception management](#exception-management)
* [Workflow statuses](#workflow-statuses)
* [Traceability and internal audit](#traceability-and-internal-audit)
* [Indicators to monitor](#indicators-to-monitor)
* [Implementation process](#implementation-process)
* [Mistakes to avoid](#mistakes-to-avoid)
* [When to consider Alkemist](#when-to-consider-alkemist)
* [Recommended next step](#recommended-next-step)

## What must be approved

An accounts payable invoice is not an isolated document.

It should be compared with:

* what the company decided to purchase;
* the purchase order or internal request;
* what was actually delivered;
* the service that was actually performed;
* the agreed commercial terms;
* the authorised amount;
* the relevant cost centre;
* the expected payment terms.

The approval process should therefore begin with a minimum set of information.

This information should normally include:

| Information                | Purpose                                                          |
| -------------------------- | ---------------------------------------------------------------- |
| Supplier                   | Identifies the party issuing the invoice                         |
| Purchase order or request  | Connects the invoice to an authorised purchase                   |
| Invoice amount             | Allows financial and threshold checks                            |
| Payment deadline           | Supports payment planning and exception handling                 |
| Cost centre                | Assigns the expense to the correct organisational area           |
| Invoice document           | Provides the formal accounting evidence                          |
| Delivery or service status | Confirms that the goods or services were received                |
| Operational owner          | Identifies the person responsible for confirming the transaction |

When these elements are missing, the administration department becomes the place where upstream problems are discovered too late.

The workflow should instead indicate immediately whether the invoice:

* is complete;
* requires additional information;
* contains a discrepancy;
* requires operational confirmation;
* must be disputed;
* can proceed to registration or payment approval.

## Roles in the process

The main roles in an accounts payable invoice approval process are usually:

* administration;
* budget or expense owner;
* operational contact;
* purchasing department;
* management.

Not every organisation requires every role for every invoice.

### Administration

The administration team is responsible for checking:

* document completeness;
* formal consistency;
* accounting references;
* payment deadlines;
* supplier information;
* duplicate documents;
* supporting documentation.

Administration should not be forced to make operational decisions it cannot verify.

### Budget or expense owner

The budget or expense owner confirms:

* that the expense is relevant;
* that it was authorised;
* that the amount is within the expected limits;
* that the cost is assigned to the correct area;
* that any deviation is acceptable.

### Operational contact

The operational contact verifies:

* whether the goods were delivered;
* whether the service was performed;
* whether the work was completed;
* whether quantities and quality are consistent with expectations;
* whether there are unresolved operational issues.

### Purchasing department or management

Purchasing personnel or management may be required when there are:

* contractual discrepancies;
* significant financial differences;
* exceptions above an approval threshold;
* supplier disputes;
* purchases made without an order;
* changes to agreed conditions.

A frequent mistake is asking everyone to approve everything.

Each approval step must have a specific purpose. When a person cannot verify a particular piece of information, their approval adds delay without reducing risk.

## Essential controls

Controls should not be unlimited.

They should focus on the points where recurring errors are most likely to occur.

Typical controls include:

| Control                   | Verification                                                         |
| ------------------------- | -------------------------------------------------------------------- |
| Invoice-to-order match    | The invoice corresponds to an authorised purchase order or request   |
| Amount verification       | The invoiced amount matches the agreed amount or permitted tolerance |
| Quantity verification     | The invoiced quantity matches the goods or services received         |
| Tax verification          | The tax rate or tax treatment is appropriate where relevant          |
| Cost centre verification  | The cost is assigned to the correct organisational unit              |
| Due-date verification     | The payment deadline is correct and manageable                       |
| Supplier verification     | The supplier matches the authorised supplier record                  |
| Payment data verification | The IBAN or other payment details are valid and approved             |
| Delivery confirmation     | The goods were delivered or the service was completed                |
| Duplicate check           | The same invoice has not already been received or recorded           |
| Supporting documents      | Orders, delivery notes, contracts, or reports are available          |

Some controls can be automated. Others require human judgement.

A system can detect a difference between the purchase order and the invoice. A person must decide whether that difference:

* is acceptable;
* requires correction;
* must be disputed;
* should be authorised as an exception;
* indicates a problem earlier in the process.

This distinction must be explicit.

When the decision remains only in an email or chat conversation, the exception does not become reusable organisational knowledge.

## Exception management

Exceptions should be classified into a limited number of clear categories.

Possible categories include:

* missing information;
* inconsistent amount;
* missing purchase order;
* unconfirmed delivery;
* supplier mismatch;
* critical payment deadline;
* duplicate invoice;
* incorrect cost centre;
* incorrect payment details;
* contractual discrepancy;
* open dispute;
* missing supporting document.

Each exception category should have:

* a responsible owner;
* a required action;
* a response deadline;
* a defined resolution condition;
* an escalation rule where necessary.

An invoice blocked without a structured reason is difficult to manage.

An invoice blocked because of an **unconfirmed delivery**, assigned to an operational contact with a response deadline, becomes manageable work.

The reopening or resolution of an exception should also be traceable.

The system should record:

* who added the missing information;
* what information changed;
* when the change occurred;
* why the invoice can now proceed;
* who authorised any exception.

## Workflow statuses

An initial workflow can use a limited number of clear statuses.

A possible model includes:

1. **Received**
2. **Under administrative review**
3. **Awaiting operational approval**
4. **Exception open**
5. **Ready for accounting registration**
6. **Approved for payment**
7. **Rejected**
8. **Correction required**

Each status should identify:

* the person or role responsible for the next action;
* the information required to continue;
* the condition for entering the status;
* the condition for leaving the status;
* any applicable deadline;
* the available actions.

Statuses should not be generic labels.

For example, **In progress** provides little useful information.

More specific statuses such as the following make the required action clearer:

* amount discrepancy to be verified;
* delivery confirmation required;
* purchase order missing;
* supplier data to be corrected;
* awaiting budget owner approval;
* payment details under review.

Specific statuses also make it easier to measure where the process is slowing down.

## Traceability and internal audit

Useful traceability should preserve the complete decision path.

The audit trail should include:

* user or author;
* date and time;
* previous status;
* new status;
* reason for the change;
* linked documents;
* comments or structured notes;
* decision taken;
* exception authorisation;
* payment approval.

The objective is not to create an unlimited number of free-text notes.

The objective is to make the process understandable.

A clear audit trail should make it possible to answer questions such as:

* Why was the invoice paid?
* Who approved the discrepancy?
* Who confirmed the delivery?
* How long was the invoice blocked?
* Which exception caused the delay?
* Was the same invoice reopened?
* Which suppliers generate the most recurring issues?
* Which departments delay approval most often?

A readable audit trail reduces dependence on individual employees and improves coordination between administration and operational departments.

It does not replace accounting controls. It provides those controls with more complete and structured information.

## Indicators to monitor

Initial indicators may include:

| Indicator                               | What it reveals                           |
| --------------------------------------- | ----------------------------------------- |
| Average approval time                   | Overall process speed                     |
| Number of invoices with exceptions      | Frequency of non-standard cases           |
| Recurring exception causes              | Structural weaknesses in the process      |
| Reopened invoices                       | Incomplete or ineffective resolutions     |
| Overdue invoices                        | Risk of late payment                      |
| Invoices without purchase orders        | Lack of upstream purchasing controls      |
| Invoices without operational references | Missing ownership or delivery evidence    |
| Time spent in each status               | Specific process bottlenecks              |
| Exceptions by supplier                  | Supplier quality or contractual issues    |
| Exceptions by department                | Internal process or responsibility issues |

These indicators should lead to operational action.

Possible actions include:

* correcting a required field;
* clarifying responsibility;
* changing an approval threshold;
* reviewing a supplier;
* improving purchase-order procedures;
* performing a control earlier in the process;
* introducing a structured exception category.

When historical data is unreliable, it is better to begin with a defined observation period.

The objective is not to create a universal benchmark. It is to understand where the company's process loses continuity.

## Implementation process

### 1. Analyse a recent sample

Select a representative sample of recent invoices.

Include invoices that were:

* approved without problems;
* blocked;
* disputed;
* corrected;
* reopened;
* paid late.

The sample should make recurring problems visible.

### 2. Define exception categories

Create a limited set of exception categories.

For each category, define:

* the owner;
* the expected action;
* the resolution condition;
* the response deadline;
* any escalation rule.

### 3. Define workflow statuses

Each status should have:

* a clear entry condition;
* a clear exit condition;
* a responsible role;
* a required next action.

Avoid creating statuses that do not change responsibility or provide useful information.

### 4. Configure a pilot process

Start with a controlled area, such as:

* one supplier category;
* one department;
* one type of purchase;
* invoices above a certain threshold;
* invoices linked to purchase orders.

A pilot makes it possible to test the model without redesigning the entire process at once.

### 5. Review the causes

Separate problems into different groups:

* data errors;
* process errors;
* supplier issues;
* missing responsibilities;
* authorisation problems;
* system limitations.

This distinction helps the company address the actual cause rather than repeatedly managing the same symptom.

## Mistakes to avoid

Avoid the following mistakes:

* treating all invoices as identical cases;
* asking people to approve documents they cannot verify;
* using free-text notes instead of structured exception reasons;
* discovering exceptions only near the payment deadline;
* failing to connect the invoice, purchase order, delivery, and operational responsibility;
* measuring only invoice volume instead of blocked or delayed cases;
* adding approval steps without a clear control objective;
* storing important decisions only in emails or chat messages;
* failing to assign an owner to each exception;
* automating a process whose rules and responsibilities are still unclear.

## When to consider Alkemist

When accounts payable invoices are delayed because confirmations are scattered across departments, emails, chats, and documents, it may be useful to begin with a pilot workflow.

Alkemist can be considered when a company needs to make the following elements explicit:

* permissions;
* workflow statuses;
* responsibilities;
* supporting evidence;
* exception categories;
* approval decisions;
* deadlines;
* audit trails.

The objective is to connect administrative work with the operational decisions that take place before an invoice can be approved.

This issue is also connected to a broader problem: management software that does not reflect the company's actual workflow.

There is also a risk in automating a process that has not first been clarified.

Technology works better when the decision-making model, responsibilities, controls, and exceptions are already understandable.

## Recommended next step

Select twenty recent accounts payable invoices and classify the reasons why they were delayed, blocked, disputed, or reopened.

For each invoice, record:

* the cause of the problem;
* the department involved;
* the responsible person;
* the time required for resolution;
* the information that was missing;
* the decision that allowed the invoice to proceed.

When the same causes appear repeatedly, the workflow should treat them as operational rules rather than random exceptions.

## Key takeaway

An accounts payable invoice approval workflow should not merely confirm that someone clicked an approval button.

It should demonstrate that:

* the purchase was authorised;
* the goods or services were received;
* the amount and conditions are consistent;
* any exception was identified and resolved;
* responsibilities are clear;
* the decision is traceable;
* the invoice is ready for registration or payment for a documented reason.