> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useglimps.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Checks

> The math check, duplicates, changed bank accounts, and what to do when one of them holds an invoice.

Glimps runs a handful of checks on every invoice. A failed check holds the invoice and says why, in words you can act on.

<h2 id="math">
  The math check
</h2>

Glimps adds the lines up and holds the result against the totals on the document. A difference means one of two things: the reading is wrong, or the invoice is wrong.

Glimps first reads the document again at a closer level. Most differences disappear there.

If a real difference is left, the invoice shows **Invoice totals do not add up**, and Glimps does not book it on its own. **Correct the lines** if the reading is off. This is the usual fix.

<h2 id="duplicates">
  Duplicates
</h2>

Glimps recognises an invoice it already has by invoice number and supplier together, or because the file is byte for byte identical. A receipt without an invoice number counts as a repeat when the same supplier charged exactly the same amount on the same day. A document that names an invoice already in Glimps and asks for exactly the same amount is flagged too.

A suspected duplicate is never booked automatically. The invoice shows **Automatic booking blocked** with "You can still send it", and names the invoice it matched. Click **View original** to compare the two. Then delete the copy you do not want, or, if they really are two invoices, choose **Not a duplicate** and send it. A person can always book it.

<Note>
  Correct the invoice number on a wrongly read invoice and the suspicion is re-examined. Delete the original and the suspicion against the copy is dropped. You do not have to clear it by hand.
</Note>

<h2 id="bank-account">
  Changed bank account
</h2>

If the IBAN on an invoice differs from the one Glimps has for that supplier, the invoice is held until a person confirms the account.

This is the check that stops invoice fraud. A mail that says "we changed banks" costs companies real money every week.

<Steps>
  <Step title="Do not trust the invoice">
    The document and the mail are both from whoever sent them. Neither proves anything.
  </Step>

  <Step title="Call the supplier">
    Use a number you already had, not one from the mail.
  </Step>

  <Step title="Record the answer">
    Confirm the account, confirm it for this invoice only, or refuse it.
  </Step>
</Steps>

Switch the check on or off under **Settings > Booking defaults**.

## VAT codes

You can require a VAT code on every line. Booking is then blocked until each line has one, both in the app and in the automatic workflow, so an incomplete booking never reaches Exact Online.

## Purchase orders and contracts

If PO matching is on, the invoice is held against the order. If the contract register is on, a recurring invoice is held against the agreement. Both are checks in the same sense: they hold the invoice and name the difference.

See [Purchase order blockers](/purchase-orders/blockers) and [Contracts](/contracts/overview).

## Due dates

Before you can send, an invoice needs payment terms or a due date. One of the two is enough. Where the due date comes from is set under [Booking defaults](/booking/defaults#due-date).

An invoice that is due soon, or already past due, and still not approved carries a badge on the authorization screens, in the list and on the invoice. Nothing is blocked. It is a nudge, because late payment costs money that automation was supposed to save.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.