Home · Solutions · Other solutions
Solution · Other solutionsA payment channel that posts daily finally gets a control that runs daily
Every card transaction matched to a receipt and a policy
Every card line is enriched, matched to a receipt or to the issuer's line-item data, tested against the programme rules and coded on the day it posts.
Executive summary
Card spend is matched, coded and checked weeks after it posts, and receipts are chased forever.
We treat every card transaction as an item to be matched, tested and coded on the day it posts.
Exceptions surface the day a transaction posts, not weeks later when the statement arrives.
SAP S/4HANA (coded card journal); SharePoint evidence archive; Power BI
Business problem
Card audit
A card is an approval that happens after the fact. The cardholder spends, the transaction posts, and the control is a monthly statement review most managers sign without reading, plus a receipt chase that never quite finishes. Coding is guesswork: cost centres come from merchant strings like "SQ *MARKET 4471", so the numbers are wrong and nobody notices until a budget holder disputes one.
The failures are specific. A blocked merchant category, a weekend purchase or a cash withdrawal is found weeks later, if at all. Two charges from the same merchant within minutes are not seen, because each line is reviewed alone. Personal spend is discovered by a manager who happens to recognise a shop. Purchasing cards, meant for low-value goods, drift towards services and subscriptions procurement never sees. Ghost cards lodged with the travel agency, the fuel supplier and the telecoms provider are reconciled against supplier files rarely, because it is tedious.
The reason all of this survives is arithmetic. Volumes are high, amounts are individually small, and the card programme is nobody's full-time job. Meanwhile the channel grows, because pushing low-value purchasing onto cards is a sensible way to cut invoice volume, and every card added makes the statement review a little more symbolic.
How it works today
- PersonA cardholder pays with a corporate or purchasing card and the transaction posts at the issuer
- WaitingThe line waits for the monthly statement before anyone looks at it
- PersonThe cardholder is asked to attach receipts and cost centres to a whole statement at once
- PersonReceipts arrive by email, in envelopes from stores, or not at all
- PersonThe administrator matches receipts to lines by amount and date, then sends reminders for the rest
- Risk of errorThe manager signs the statement review without opening the lines, so blocked categories, duplicates and personal spend pass
- PersonTransactions are coded to cost centres from merchant strings that mean nothing to the coder
- WaitingThe card journal is posted at month end; ghost card statements meet the supplier files a few times a year
Why the current process costs more than it appears
The bill that never reaches the budget.
- Cardholder time is invisible because it is spread thinly. A few minutes per line to find a receipt, choose a code and answer a chaser is nothing to one person and hundreds of hours across 240 stores.
- Administrators spend their week on matching that a machine does better, the one part of their job requiring no judgement.
- Miscoding does its damage quietly. Cost-centre reports drift, purchasing-card spend stays hidden, and the contract a recurring merchant deserves is never negotiated.
- Late detection means no recovery. A duplicate found six weeks after posting is written off as immaterial, one line at a time, and the write-offs are never totalled.
- Repeat behaviour is identified by memory, so only the egregious cases are caught, and the early conversation that would have ended it never happens.
Cost of inaction
Card programmes grow because they are convenient, and the control does not grow with them. The transaction count rises with stores and headcount, the Chasers spreadsheet gets longer, and receipt compliance falls because the chase is losing. Coding errors accumulate in cost-centre reports until a budget holder disputes a number that nobody can trace back to a merchant.
Ghost cards carry the largest lines and go unreconciled longest, because the people who understood the supplier files have moved on. None of this is dramatic in any single month; it is a slow loss of control over a growing amount of money, and the audit finding that eventually names it will ask why a daily payment channel was checked monthly.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A regional retail chain, 240 stores and central functions, about 1,100 active cards: corporate travel cards for managers, purchasing cards for store consumables and maintenance, and ghost cards lodged with the travel agency, the fuel supplier and the telecoms provider; SAP is the ledger, Microsoft 365 the workplace.
Around 18,000 card transactions a month at an average of €135, so roughly €2.4 million of monthly card spend. The issuer sends a daily transaction file carrying line-item data for fuel and some retail merchants.
Three administrators run the programme alongside other duties. Receipts arrive in a shared mailbox and in envelopes from stores, and the monthly statement review is a signature.
The control runs monthly on a channel that posts daily, so detection sits weeks behind the spend and the receipt chase is permanently losing.
The issuer's daily feed becomes a queue; each line is enriched with cardholder, programme and merchant data, matched to a receipt or audited from the line-item data, tested against the rules for its card type, then coded and posted. Only flagged lines reach a person.
In the modelled case exceptions surface on the day they post rather than after the statement, receipt chasing collapses to one task naming one line, and the card journal is complete and correctly coded before the close begins. These are modelled figures.
Proposed solution
We treat every card transaction as an item to be matched, tested and coded on the day it posts. A UiPath robot collects the issuer's daily file, or calls its API, and loads one queue item per transaction into UiPath Orchestrator. Each item is enriched: cardholder and manager from HR master data, card programme and its rule set, merchant category, and the issuer's line-item data where the merchant provides it.
Receipts reach the process through three doors: a Microsoft Teams task, the shared mailbox and the expense system. UiPath Document Understanding reads them with the pre-trained Receipts model, and the robot matches amount, date and merchant. Where no receipt exists but the line-item data is complete, the transaction is audited and coded from that data, and a receipt is asked for only above a threshold your finance team sets. That one decision removes most of the Chasers spreadsheet.
The rules then run as DMN decision tables in UiPath Maestro, differently for each programme: single-transaction and monthly limits, blocked merchant categories, duplicates inside a time window, weekend and leave-period spend, cash withdrawals, personal-spend indicators, repeat counts over a rolling period. Clean lines are coded and posted to SAP the same day. Flagged lines become UiPath Action Center tasks: the cardholder attaches a receipt or writes a justification in Teams, the administrator decides, and a repeat case reaches the manager with the count attached. Ghost card lines are reconciled every night against the travel agency's bookings, the fuel supplier's file and the telecoms billing detail.
Two design choices matter more than the technology. The cardholder is asked once, about one named line, in the application already open. And the rules are owned by treasury, so a limit change is a table edit under change control rather than a development request.
UiPath Orchestrator queues, triggers, credential stores and audit; UiPath Document Understanding pre-trained Receipts model and Validation Station; UiPath Maestro with DMN decision tables; UiPath Action Center tasks as actionable notifications in Microsoft Teams; UiPath Integration Service connectors for Microsoft Teams, Microsoft Outlook 365 and SAP
The enrichment layer over HR data, the card programme registry and the merchant category map; the matching logic and its thresholds; the rule set per programme with repeat-violator counters; the ghost card reconciliation; the coding and posting logic; and the Power BI reporting
The issuer's daily transaction feed over SFTP with key-based authentication, or its API through Connector Builder; the travel, fuel and telecoms supplier files used for the ghost card reconciliation
How the automated process works
- AutomationThe issuer's daily file or API call lands in an Orchestrator queue, one item per transaction
- AutomationEach line is enriched with cardholder and manager from HR data, the programme and its rules, the merchant category and any line-item detail
- AutomationReceipts from Teams, the shared mailbox and the expense system are read and matched on amount, date and merchant
- AutomationThe rule set runs for that programme: limits, blocked categories, duplicates in a time window, cash withdrawals, personal-spend indicators, repeat counts
- AutomationClean lines are coded and posted to SAP the same day, with receipt and rule trail archived on SharePoint
- PersonA flagged line becomes a Teams task naming merchant, amount and date; the cardholder attaches a receipt or writes a justification
- PersonThe administrator decides the exception, and repeat cases go to the manager with the count attached
- AutomationGhost card lines meet the supplier files overnight, and Power BI refreshes compliance by store and programme
Human-in-the-loop model
Automation handles
- Daily collection of every transaction into a queue and enrichment with cardholder, programme and merchant data
- Receipt reading and matching, and the use of line-item data where a receipt does not exist
- The rule set per programme, with duplicate windows and repeat-violator counts
- Coding and posting of clean lines, and the nightly ghost card reconciliation
People decide
- Whether a flagged line has an acceptable receipt or justification, supplied by the cardholder
- Every exception outcome, which the administrator owns
- Repeat cases, card suspensions and limit changes, which stay with manager and treasury
- The programme rules themselves, changed under documented control
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- the issuer's daily transaction file with line-item data
- receipt images from Microsoft Teams, the shared mailbox and the expense system
- supplier files behind the ghost cards
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Document Understanding
- UiPath Maestro
- UiPath Action Center
- UiPath Integration Service
Target systems
- SAP S/4HANA (coded card journal)
- SharePoint evidence archive
- Power BI
Human touchpoints: cardholder tasks in Microsoft Teams; the administrator review queue; the manager view of repeats
Technologies used
collect the daily feed into a queue, run enrichment and rules, hold credentials and the audit trail
Apre-trained Receipts model reads receipt images, with Validation Station for low-confidence fields
Aexecutes the rule set per card programme, including duplicate windows and repeat counts
Acardholder and administrator tasks carrying merchant, amount and date of one named line
Awhere cardholders attach a receipt or a justification without leaving their day
Areceipt intake from the shared mailbox, task delivery, ledger posting
Aa coded card journal posted daily instead of built at month end
Areceipt compliance by store, exception rate by rule, open cardholder tasks by age
AIllustrative economic model
A model, not a promise.
Everyone who touches a card line pays a little of the two minutes: the cardholder hunting a receipt and answering the chaser, the administrator matching and coding. Matching, line-item coding and automatic posting absorb 70% of that, so the share is folded into the volume below: 12,600 of the 18,000 monthly transactions rather than all of them, at €38 an hour blended. What the rules stop sits outside the box: at €2,430,000 of monthly card spend and 0.4% flagged and stopped or recovered, that is €9,720 a month. Both percentages are assumptions, measured at no client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Exceptions surface the day a transaction posts, not weeks later when the statement arrives
- Receipt chasing mostly disappears: the cardholder is asked once about one named line, and line-item data covers many transactions without one
- Cost centres are right, because coding comes from programme, merchant and line-item data, not a merchant string
- Duplicates, blocked categories and personal spend are caught consistently, because every line meets the same rules
- Repeat behaviour becomes a count rather than an impression, so the manager conversation happens early
- The close speeds up, because the card journal is complete and coded before month end, not during it
The management view
- The treasurer reads the programme daily: spend by card type, exceptions by rule, receipt compliance by store, open cardholder tasks by age
- Procurement finally sees purchasing-card spend by merchant, which is where the missing contracts are
- Every match, rule outcome and decision is logged, so cards get the audit trail payables has rather than a signed statement
- Programme ownership becomes explicit: rules are documented per card type and changed under control, so a limit is a decision, not a habit
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Card data is treated as payment data: the feed carries masked card numbers only, and files move over SFTP with key-based authentication or the issuer's API
- The robot posts with a dedicated ledger account limited to the card journal; it cannot change a limit or suspend a card, which stay with the administrator on the issuer portal
- Segregation of duties holds between the cardholder who justifies, the administrator who decides and the manager who reviews repeat cases
- Credentials sit in the UiPath Orchestrator credential store or an external vault such as Azure Key Vault, and every rule outcome and decision is logged and attributable
- Receipt images stay in your Microsoft 365 tenant; extraction runs in the EU region of UiPath Automation Cloud under the UiPath AI Trust Layer, with masking and logging
- Cardholders are told that transactions are checked daily, and the personal-spend rules are documented and applied identically to everyone, as employee-monitoring rules in most of Europe require
Why now
Issuers now publish daily transaction feeds and, for a growing share of merchants, line-item data detailed enough to replace a receipt for coding and audit
Companies are moving low-value purchasing onto cards to cut invoice volume, which only makes sense if the card control is at least as good as the invoice control it replaces
The pieces that used to be projects are now configuration: receipt reading is a pre-trained model, and the modelled €15,960 a month absorbed is larger than anything ever spent on running the programme
Relevant executive roles
A daily payment channel with a daily control, and a card journal that no longer holds up the close
Visibility across corporate, purchasing and ghost cards, limit discipline, and misuse found early rather than annually
Correct cost centres, an end to receipt chasing, and the audit trail payables already has
Purchasing-card spend by merchant, showing precisely where a contract is missing or bypassed
Common questions and objections
Issuer flags cover a few generic rules and stop at the portal. This applies your policy, your HR data and your receipts, and posts the coded result into your ledger the same day.
They are chased today, three times, by email, about a statement nobody can decode. One task naming the merchant, amount and date, answered in Teams in seconds, is less irritating, not more.
The agency bills through your card, so reconciling its charges against your own bookings is your control, not theirs. Automating it is the only realistic way it happens daily rather than twice a year.
When this is not the right solution
- A small programme of a few dozen cards whose administrator genuinely reviews every line already
- The issuer cannot provide a daily feed; a monthly file supports matching and coding but not a daily control
- Card transactions already flow into an expense system whose audit rules are tuned and used
- Nobody owns the card policy, so no one can decide the rules or the limits they enforce
A question for the next management meeting
Between accounts payable and the card programme, which of our two largest payment channels is actually controlled, and what evidence would we put in front of an auditor?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- An analysis of your card programmes, the issuer feed and its line-item coverage, the receipt channels and exception log
- The rule set per card type, agreed with treasury and procurement and written as tables they own
- The enrichment layer: HR data, the programme registry and the merchant category map
- Receipt reading with matching thresholds and the rule that decides when line-item data is enough
- Coding and posting to the ledger, the Teams tasks for cardholders and administrators, and the ghost card reconciliations
- Power BI on receipt compliance, exception rate and open tasks, with training for administrators and cardholders
We need from you
- Three months of transaction files, with line-item data where the issuer supplies it
- The card policy per programme and its current limits, with an owner able to decide them
- Access to HR data for cardholder and manager, and to the card journal in the ledger
- The supplier files behind the ghost cards and a named administrator as process owner
Stages
Discovery
Programmes, feeds, line-item coverage, receipt channels, today's exceptions
Rule design
The rule set per card type with treasury, thresholds and repeat-case handling
Shadow run
The rules run on live transactions in one programme and region while administrators judge precision
Rollout
Live tasks for purchasing cards, then corporate cards, then ghost cards and their reconciliations
Run
Monthly rule review with treasury, compliance reporting, change control on limits
Departmental. Effort follows the number of card programmes and their rule differences, the coverage of the issuer feed, and how many receipt channels stay alive during the transition.
Your second-largest payment channel is reviewed once a month, with a signature.
Send us one month of card activity at transaction level, with line-item data where your issuer provides it and your card policy alongside. We return what our rule set finds, by programme and by rule.
Show us one month at transaction levelThe neighbouring process usually has the same problem
Stop paying nine expense claims in ten on trust because nobody has time to check them against policy.
View solution Other solutionsEvery expense report audited before the money leavesA sample checked after payment finds errors it cannot recover and misses the duplicates entirely.
View solution Other solutionsSplit payments and double-claimed meals found with evidenceNobody splits a purchase in front of an approver. They split it across three receipts and two weeks.
View solutionIndustries we deliver this in most oftenManufacturing & industryServices & ITFinance & insuranceShared services