AI for Finance · Solutions

Odd payments, edits and refunds go to a person for review.

AI Fraud Detection reads payments, vendor records, refunds and expense claims, then flags the ones that break your usual pattern for a person in finance to look at. The finance lead decides. The software pays and reports nothing. It needs a ledger with a few seasons of consistent history, so that it can learn what normal looks like for your vendors, staff and bank.

Share your requirements

What it is

Most fraud is ordinary. A vendor’s bank account changes by email, a clerk splits one bill into two to stay under the approval limit, and a refund goes to a card nobody recognises. Each one looks routine when read alone in the ledger, which is exactly why a tired reviewer at month end lets it through.

GullySystem sets this up inside the accounting and payables software you already run, using your own ledger to learn what a normal week looks like. Every flag goes to a named reviewer. The software pays and reports nothing.

Where it goes wrong today

The problems this is meant to ease.

Supplier bank details change quietly

Nobody notices a changed account. A supplier’s account number is edited after a convincing email arrives, the next payment run pays into it, and nobody sets the new details beside the old ones first.

Bills are split to dodge a limit

One bill becomes two. Each part stays under the approval limit, so neither reaches the second approver, and read one at a time both look like ordinary invoices from a known supplier.

Duplicates slip through with new numbers

The same bill returns renumbered. Accounts payable pays it twice, and only the vendor’s statement shows the double payment, often months after the money has gone out.

Refunds and credit notes go unread as a group

Each refund looks fine alone. A refund lands on a card that never paid, or the person who raised a credit note also releases it, and nobody reads these lines as a group.

Reviewers read everything or nothing

Review turns into a skim. Without a ranked list, month end means scrolling thousands of lines, the odd ones hide among normal ones, and the careful reviewer runs out of time.

Inside the module

What AI fraud detection does.

Vendor details that change

A changed supplier bank account is flagged. The flag names who edited the record, when it happened, and which open invoices would now be paid into the new account.

Duplicate and split invoices

The same bill can arrive twice with a changed invoice number, or as two smaller bills that each stay under the approval limit. Both are shown together.

Refunds and credit notes

Refunds to a card that never paid, or credit notes raised by the person who later issues the payment, are listed with their history for review.

Expense claims that repeat

The same receipt submitted by two staff, claims clustered just under the limit, and mileage that does not fit the calendar are marked for the approver. Marking is not accusing.

One ranked review queue

Flags arrive in one ranked queue. The reviewer marks each one as explained, queried or escalated, and the reason is kept against the entry for the next audit.

Rules and learned patterns together

Fixed rules run beside patterns learned from your own ledger, such as no payment to a vendor created in the last week. Rules catch the known trick. Learned patterns catch the stranger one.

False alarms taught away

A vendor who always invoices in bursts is learned after one reviewer marks the first burst as explained, with a reason that stays on the record for later. Noise falls as the queue learns.

Case reports for each investigation

Each flagged case gathers the entries, the edits, the reviewer’s notes and the final outcome into one report that an auditor can read cold. No emails need digging up.

Where it gets used

What this looks like in a working week.

Wholesale distributor

A wholesaler with several hundred vendors sees a bank change on a small supplier, a bill just under the limit and an old invoice repeated. The payables lead calls first.

Clinic group

A clinic group reviews staff expense claims where two doctors submit the same taxi receipt and the mileage does not fit the duty roster. The practice manager asks both doctors.

Online retailer

An online retailer lists refunds sent to cards that differ from the paying card, grouped by the agent who raised them, so the support lead spots repeats. The lead talks to the agent first.

Repair workshop

A repair workshop spots a parts supplier created only last week and already paid, with an invoice for stock nobody remembers receiving at the counter. The owner holds the next payment.

Building contractor

A building contractor sees one subcontractor’s invoices split across two job codes so each passes under the site manager’s limit and skips the director’s signature. The finance lead reads both together.

Who touches it

The people who open this every day.

Finance controller

Reads the weekly flag queue before approving the payment run. Holds back any payment that needs a call to the vendor first.

Accounts payable clerk

Sees why a bill was held. Marks it explained only after the vendor confirms the new details by phone, using a number that was already on file before the change.

Business owner

Gets a short weekly list. Reads the few items that deserve a second look, and signs the payment run only when the open ones have an answer written beside them.

Internal or outside auditor

Reads the kept record of every flag, who reviewed it and what they decided, so a year-end sample starts from written evidence and not memory.

How it is set up

From first conversation to daily use.

Map the payment path
Sit with the finance lead and trace how bills, refunds and claims travel from first entry to the payment run, listing every person who can edit vendor records. Each gap is a trick to watch.
Prepare the ledger history
Merge duplicate vendors, tie payments to invoices and export the edit history of vendor fields, so the software can see who changed a bank account and when. Bad data makes noisy flags. Clean data comes first.
Trial on a closed period
Run the checks over a closed period, using real invoices, payments and refunds where your team already knows which entries turned out to be wrong. Compare each flag with what people remember. Note which rules are too loud.
Check the queue with the reviewers
Have the controller, the payables clerk and the auditor read a real queue together, adjust the rules, add reasons and agree who may close each kind of flag. Their questions shape the final rules.
Go live beside the payment run
Switch on the weekly queue so reviewers read it before every payment run is approved by the people who already sign it off today. Approval steps stay as they are.
Review after a few payment runs
After a few payment runs, count which flags were confirmed, which were noise and which problems arrived by another route to the finance team. Weak rules are retired. Reviewers’ requests become new rules.

Measuring it

How you would know it is working.

Record where you stand before it goes live, so the change is measured against your own figures.

Confirmed fraud detection counts flags that proved to be real problems, measured against the confirmed cases your team can list from the year before launch.
Reviewers closing a flag as explained counts toward the false positive rate, set against the first month of trial flags, before any rule was changed.
Investigation efficiency is the time between a flag appearing and a decision being recorded, with the baseline read from the email threads and ledger notes of similar past cases.
Case reporting is the number of flagged cases that end with a written report, set against the cases that were settled by phone or email alone before go-live.
Bank changes confirmed is how many edits to a supplier’s bank details were checked by phone before payment, measured against a sample of past edits in the vendor history.

Used responsibly

Where a person stays in charge.

A person decides every case

Flags are questions, not accusations. A named reviewer reads the reasons, speaks to the people involved and records what happened, while the software holds no payment and reports nothing to anyone outside.

Staff names and bank details stay restricted

Flags can contain personal and banking data. Access follows the roles in your ledger, exports go only to the reviewers you name, and your security adviser agrees where the data may be stored.

Some fraud will still pass

Some fraud can still pass. Collusion between trusted staff, or a false invoice from a vendor with a clean history, leaves little trace in the records, so it narrows the search without replacing audits.

Rules differ by country

Reporting duties vary by country. What must be reported, to whom and how soon is settled with your own lawyer or accountant, because it gives no tax, legal or financial advice.

How it fits

It is one part of a system, not an island.

A module earns its place by what it passes to the next one. These are the connections we set up most often.

Accounting ledger and accounts payable
Bank feeds and payment files
Expense and reimbursement software
Approval workflows
Email alerts to the reviewer

Already built in

Products that include it.

Built for you

How we would put it in.

Common questions

Questions owners ask about AI fraud detection.

Will it stop a payment on its own?

Stopping is your decision. Each flag shows its reasons. The payment run you already operate, with its own approvers, decides whether a payment goes ahead, waits or is cancelled, and the software never touches it.

What history does it need before the flags are useful?

A few seasons of consistent postings, with vendors entered once each and payments tied to invoices, give it a normal to compare against. Messy books produce noisy flags. Tiny ledgers need a clerk instead.

Does it catch every kind of fraud?

No tool catches every case. It sees only what the records show, so two trusted staff acting together, or a false invoice from a vendor with a clean history, can still pass through.

Is this legal or audit advice?

Reporting and investigating suspected fraud falls under local rules that vary between countries, so your accountant or lawyer decides what follows a flag. This tool prepares data for your reviewer. Tax and legal opinions are not part of what it produces.

What does it connect to?

It reads your accounting ledger, payables, bank feeds and expense software, so the setup depends on what each one can export or share through an interface. A file upload covers the rest.

Who sees the flags, and what about privacy?

Only the reviewers you name see them. Staff names and bank details can appear in a flag, so access follows the roles already in your ledger, and your security adviser decides where the data lives.

How much effort does it take to start?

Most of the effort is human. Vendor records need tidying, reviewers need naming, and for the first weeks your finance team will spend real time marking flags as explained or queried.

When is it not worth setting up?

A business with a few vendors and one person who approves every bill already sees everything, so a monthly read of the ledger does the same job without software.

Who needs it most

Businesses that ask for this.

Next to it

Modules that work with it.

Talk to us

Tell us how you handle AI fraud detection today.

A spreadsheet, a register or another system: say which, and we will tell you plainly what is worth changing.

No obligation
A reply within one business day
Your details stay private

Start with your requirements

Seven short steps that tell us what you need. An engineer reads them before getting in touch.