1 · When to use it

Your receivables live across supplier portals, PDF attachments and three different email threads, and nobody has a single view. Use this when chasing is late because finding is hard.

Not for disputed invoices. Those need a human from the first message.

2 · Required inputs and access

Inputs

• Every portal and inbox where invoices or remittances appear
• Payment terms per client
• Escalation ladder: who gets chased at 30, 60, 90 days
• Your chaser templates by age band
• Known disputes, so they are excluded

Access

• Accounting system
• Client AP portals, signed in
• Finance inbox
• Contract or CRM record for payment terms

If any of this is missing, stop and name which one. Do not substitute a nearby source.

3 · Sequence of work

1. Pull open invoices from the accounting system. This is the source of truth for what is owed.
2. Check each portal for status: received, approved, scheduled, paid, rejected, or not found. A portal saying scheduled changes the chaser entirely.
3. Search the finance inbox for remittance advice matching open invoices. Payments arrive without being reconciled more often than anyone admits.
4. Exclude anything on the known-dispute list.
5. Calculate true age against the contracted payment terms, not the invoice date. Terms vary and this is where most chasers embarrass themselves.
6. Band by age and select the matching template and escalation contact.
7. Draft each chaser. Reference the specific invoice number, amount, date and portal status.
8. Build the ledger for review.

4 · How to validate the result

• Every chaser carries the correct invoice number and amount. Verify against the accounting system, not against the previous chaser
• No invoice showing scheduled or paid in a portal gets a chaser
• Ageing is calculated from terms, not from invoice date
• Disputed items are excluded. Check the list explicitly every run
• Escalation contacts match the age band

5 · What to return

A receivables ledger: Invoice | Client | Amount | Issued | Terms | True age | Portal status | Band | Escalation contact | Draft

Above it: total outstanding, total past terms, and anything that moved band since last run. Below it, a separate section for invoices that could not be located in a portal at all — that list is usually the real problem.

6 · What requires approval

• Sending any chaser
• Escalating to a new contact
• Any communication about a disputed invoice
• Writing anything to the accounting system

7 · No-data and stale-data policy

If a portal is unreachable, mark the invoice [portal unchecked] and do not draft a chaser for it. Chasing an invoice that was paid last Tuesday costs more goodwill than chasing late costs cash.

If the accounting system is unavailable, abandon the run. Never chase from a cached ledger.

Save it

Save this as a skill called “INVOICE-CHASE”. Include the portal list, the payment terms per client, the escalation ladder, the dispute exclusion list, the rule that ageing is calculated from contracted terms, the rule that unchecked portals produce no chaser, and the rule that every send requires my approval.

Run it as a routine

Every Tuesday at 08:00 Europe/Paris, run INVOICE-CHASE across all client portals and the finance inbox. Post the ledger and the drafts in this conversation. Send nothing. If the accounting system is unavailable, abandon the run and tell me.

1 · When to use it

Spend is committed across POs, cards and supplier invoices, and the monthly close involves someone squinting at three exports. Use this when variances are being discovered late.

Not a replacement for a finance system. This is a detection layer on top of one.

2 · Required inputs and access

Inputs

• Budget by cost centre or project
• PO register
• Actuals source
• Materiality threshold, in both absolute value and percentage
• The period being reconciled, stated explicitly

Access

• Finance or ERP system
• Procurement or PO system
• Corporate card statements
• Supplier invoice store

3 · Sequence of work

1. Fix the period boundaries and state them. Every subsequent figure is meaningless without them.
2. Pull budget, POs and actuals for the period. Record the three totals before any matching.
3. Match actuals to POs. Report the match rate. An unmatched actual is the highest-value finding in this whole skill.
4. Calculate variance by cost centre: budget against committed against actual. Committed and actual are different things and conflating them hides overspend.
5. Apply the materiality threshold. Suppress everything below it into a single summary line.
6. For each material variance, identify the largest contributing transactions and, where possible, the reason.
7. Flag anything with no PO, no approver, or a supplier not on the approved list.
8. Build the reconciliation.

4 · How to validate the result

• The three totals reconcile to the source systems. If they do not, stop and report the discrepancy rather than proceeding
• Period boundaries are consistent across all three sources — off-by-one periods are the single most common cause of phantom variance
• Committed and actual are shown separately, never summed
• Every material variance names contributing transactions
• Currency and FX rate are stated where multiple currencies appear

5 · What to return

A reconciliation by cost centre: Cost centre | Budget | Committed | Actual | Variance | Variance % | Material? | Top contributors

Three exception lists below it: actuals with no matching PO, spend from unapproved suppliers, and transactions with no recorded approver. At the top: the three control totals and the PO match rate.

6 · What requires approval

• Posting any adjustment or journal
• Contacting a supplier or a budget holder
• Reclassifying any transaction
• Sharing the reconciliation outside finance

7 · No-data and stale-data policy

If any of the three sources is unavailable, do not produce a partial reconciliation. Report which source failed and stop. A reconciliation missing one leg is not a reconciliation, and it will be read as one.

If actuals for the period are not yet closed, state that prominently at the top of the output.

Save it

Save this as a skill called “SPEND-RECON”. Include the materiality thresholds, the requirement to state period boundaries explicitly, the rule that committed and actual are never summed, the requirement to report control totals and PO match rate, the rule that a missing source aborts the run, and the rule that all adjustments and all external contact require my approval.

Run it as a routine

On the fifth working day of each month at 08:00 Europe/Paris, run SPEND-RECON for the prior calendar month. Post the reconciliation in this conversation. Post nothing to the finance system. If any source is unavailable, abandon the run and name the failed source.

1 · When to use it

Software spend has grown by accretion and nobody owns the total. Use this when you suspect the number is bigger than anyone thinks, which it always is.

High risk despite feeling like housekeeping. Cancelling the wrong thing breaks something on a Monday morning.

2 · Required inputs and access

Inputs

• Card statements and AP records covering at least 12 months
• Known-critical list: anything that must never be flagged, regardless of usage
• Usage data source, where one exists
• Renewal and notice-period terms if available

Access

• Corporate card statements
• AP or accounting system
• Identity provider or SSO logs, for genuine usage signal
• Vendor admin portals, signed in

3 · Sequence of work

1. Pull 12 months of card and AP transactions. Identify every recurring software charge, including annual ones that fire once and are easy to miss.
2. Normalise: the same vendor billed through three entities with three descriptors is one subscription.
3. Annualise every cost. Monthly charges get multiplied; annual charges get shown as-is. State the basis.
4. For each, pull licence count against active users from SSO or the vendor admin portal. Unused seats are usually a bigger number than unused tools.
5. Cross-check the known-critical list and remove those from any recommendation.
6. Identify notice periods and renewal dates. A subscription with a 90-day notice period that renews in 60 days is a different decision to one you can cancel today.
7. Rank by annual saving, adjusted for switching cost and risk.
8. Build the audit. Cancel nothing.

4 · How to validate the result

• Nothing on the known-critical list appears in the recommendation list. Check this twice
• Duplicate vendor entries are merged, not double counted
• Annualisation basis is stated for every line
• Usage figures carry their measurement window
• Notice periods and renewal dates are shown wherever a cancellation is recommended

5 · What to return

A ranked audit: Vendor | Annual cost | Basis | Licences | Active users | Utilisation | Renewal | Notice | Recommendation | Annual saving

Three totals at the top: total annual software spend, spend on tools with under 20% utilisation, and identified annual saving. A separate section for anything where usage could not be measured, marked as unknown rather than assumed unused.

6 · What requires approval

• Cancelling anything
• Reducing any licence count
• Contacting any vendor
• Changing any plan or tier

7 · No-data and stale-data policy

If usage data is unavailable for a vendor, mark utilisation [unknown]. Do not infer that unmeasurable means unused — that inference is how someone’s authentication provider gets cancelled.

If card or AP data covers less than 12 months, state the actual window and note that annual subscriptions may be missing.

Save it

Save this as a skill called “SUBSCRIPTION-AUDIT”. Include the known-critical exclusion list, the vendor normalisation rules, the requirement to state the annualisation basis, the rule that unmeasurable usage is marked unknown rather than assumed unused, the requirement to show notice periods before recommending cancellation, and the rule that every cancellation and every vendor contact requires my approval.

Run it as a routine

On the first Monday of each quarter at 08:00 Europe/Paris, run SUBSCRIPTION-AUDIT over the trailing 12 months. Post the audit in this conversation. Cancel nothing and contact no vendor. Mark any unmeasurable usage as unknown.

1 · When to use it

You have an agreed rate card and suppliers who quote off it inconsistently. Use this where the rates are contractual and the checking is currently manual.

Also works in reverse: checking that your own team is quoting the client correctly.

2 · Required inputs and access

Inputs

• The current rate card, with effective dates
• The quote, invoice or estimate to check
• Tolerance: what deviation is worth flagging
• Rules for anything not on the rate card
• FX policy if rates and quotes are in different currencies

Access

• Document store holding the rate card
• Wherever quotes arrive
• Contract, for any negotiated exceptions

3 · Sequence of work

1. Load the rate card version effective on the quote date. Using the current version against an older quote produces false deviations.
2. Extract every line from the quote: role or item, quantity, unit, unit rate, extended total.
3. Match each line to a rate card entry. Unmatched lines go to an exceptions list rather than being waved through.
4. Compare unit rates. Calculate deviation in absolute value and percentage.
5. Recalculate every extended total independently. Arithmetic errors in quotes are more common than rate deviations and nobody checks for them.
6. Check the blended rate across the whole quote against any agreed blended cap.
7. Apply the tolerance and separate material deviations from noise.
8. Produce the check with a total exposure figure.

4 · How to validate the result

• The rate card version used matches the quote date. State both
• Every quote line is either matched or on the exceptions list. No line is silently dropped
• Extended totals were recalculated, not copied from the quote
• Deviation percentages are calculated against the rate card figure, not the quoted figure
• Currency and FX rate are stated where relevant

5 · What to return

A line-by-line check: Quote line | Quoted rate | Card rate | Deviation | Deviation % | Qty | Value impact | Status

Above: rate card version and effective date, quote date, total quoted, total at card rates, and total exposure. Below: exceptions and arithmetic errors, listed separately because they need different conversations.

6 · What requires approval

• Sending any challenge or query to the supplier or client
• Approving or rejecting the quote
• Any negotiation position

7 · No-data and stale-data policy

If the rate card is unreachable, do not check against remembered rates. Report the failure and stop.

If no rate card version covers the quote date, say so explicitly rather than defaulting to the nearest one.

Save it

Save this as a skill called “RATE-CARD-CHECK”. Include the tolerance threshold, the rule that the rate card version must match the quote date, the requirement to recalculate every extended total independently, the rule that unmatched lines go to exceptions rather than being passed, and the rule that all supplier or client contact requires my approval.

Run it as a routine

Run on demand against a specific quote, or every weekday at 09:00 Europe/Paris against anything new in the quotes folder. Post the check in this conversation. Contact no supplier.

1 · When to use it

A retained or scoped engagement has been running long enough that delivery has drifted from the contract. Use this before a renewal, a review, or any conversation about fees.

Drift runs both ways. Under-delivery is a risk; over-delivery is unbilled revenue and a precedent you are setting for free.

2 · Required inputs and access

Inputs

• The signed SOW or contract, with the deliverables schedule
• Actual delivery records for the period
• Any approved change orders or variations
• The period under review, stated explicitly
• Unit values from the pricing model, if deliverables are priced

Access

• Contract store
• Project or delivery tracking system
• Timesheets or resource data if the model is FTE-based
• Change order log

3 · Sequence of work

1. Extract the contracted deliverables schedule: item, volume, frequency, service level. Note the contract version and date.
2. Apply every approved change order in date order. The baseline is the contract as varied, not the original signature.
3. Pull actual delivery for the period from the tracking system.
4. Match actuals to contracted lines. Anything delivered that maps to no line is scope creep. Anything contracted with no delivery is a shortfall.
5. Compare volumes line by line. Show contracted, delivered, and variance.
6. Where the pricing model has unit values, apply them so the drift carries a number rather than a feeling.
7. Check service levels separately from volumes. Delivering the right count late is still drift.
8. Produce the drift analysis.

4 · How to validate the result

• The baseline includes every approved change order. List them so this is auditable
• Delivered items that map to no contracted line appear in the creep list, not folded into the nearest line
• Volumes reconcile to the tracking system totals
• Valuation, where applied, uses the contracted unit values and shows the calculation
• Service level analysis is separate from volume analysis

5 · What to return

A drift analysis: Contracted line | Contracted volume | Delivered | Variance | SLA met? | Unit value | Value impact

Two lists below: scope creep (delivered, not contracted, with estimated value) and shortfall (contracted, not delivered). At the top: net value drift, the number of change orders applied, and the single largest drift item in each direction.

6 · What requires approval

• Raising drift with the client or the delivery team
• Drafting any change order or variation
• Any position on billing, credit or recovery
• Sharing the analysis outside the commercial team

7 · No-data and stale-data policy

If delivery records are incomplete for part of the period, state which part and analyse only the complete portion. A drift figure covering an unstated partial period will be quoted as if it covered the whole thing.

If the change order log is unavailable, abandon the run. Analysing against an unvaried baseline produces confidently wrong numbers.

Save it

Save this as a skill called “SOW-DRIFT”. Include the requirement to build the baseline from the contract as varied by all approved change orders, the rule that unmapped delivered items go to a creep list, the requirement to analyse service levels separately from volumes, the rule that a missing change order log aborts the run, and the rule that all client and delivery team contact requires my approval.

Run it as a routine

On the first working day of each month at 08:00 Europe/Paris, run SOW-DRIFT for the prior month against the current contract baseline. Post the analysis in this conversation. Contact nobody. If the change order log is unavailable, abandon the run.

1 · When to use it

Expense submission is a recurring chore and policy rejections are costing more time than the expenses are worth.

Genuinely low risk, which makes it a good first automation to build confidence on.

2 · Required inputs and access

Inputs

• The expense policy, in full
• Where receipts accumulate (inbox, photo folder, card feed)
• Cost centre and project coding rules
• Submission deadlines

Access

• Expense system, via connector or browser
• Email, for receipt attachments
• Card statements, for matching
• Calendar, for meeting context on client entertainment

3 · Sequence of work

1. Gather receipts from every configured source for the period. Deduplicate: the same receipt arrives as a photo and an email attachment more often than not.
2. Extract from each: date, merchant, amount, currency, VAT where shown, category.
3. Match receipts to card transactions. Card charges with no receipt are the blocking problem — surface those first.
4. Apply coding rules to assign cost centre and project.
5. Check each against policy: caps, categories requiring justification, categories not reimbursable, receipt requirements, date limits.
6. For anything requiring justification, draft one from calendar context where available.
7. Flag anything that will be rejected, with the specific policy clause.
8. Assemble the submission pack.

4 · How to validate the result

• No duplicate claims. Match on merchant, date and amount together, since same-day same-merchant duplicates are real
• Currency conversions state the rate and date used
• Every policy flag cites the specific clause, not “policy”
• Card transactions with no receipt are listed prominently
• Coding follows the stated rules with no improvisation

5 · What to return

A submission pack: Date | Merchant | Amount | Currency | Category | Cost centre | Policy status | Clause | Justification

Three sections above it: ready to submit, needs justification, will be rejected and why. A missing-receipts list at the bottom, since that is the item that actually needs you to go looking.

6 · What requires approval

• Submitting the expense claim
• Any claim over the stated single-item threshold
• Anything flagged as policy-breaching, even if you intend to submit it with justification

7 · No-data and stale-data policy

If the card feed is unavailable, submit only receipt-backed items and note that unmatched card charges could not be checked this run.

If a receipt image is unreadable, flag it as unreadable rather than guessing the amount. A guessed expense amount is a compliance problem, not a rounding error.

Save it

Save this as a skill called “EXPENSE-RUNNER”. Include the policy caps and categories, the coding rules, the deduplication rule matching on merchant, date and amount together, the requirement to cite the specific policy clause on every flag, the rule that unreadable receipts are flagged rather than estimated, and the rule that submission requires my approval.

Run it as a routine

Every Friday at 15:00 Europe/Paris, run EXPENSE-RUNNER for the week’s receipts. Post the submission pack in this conversation. Submit nothing. List any card charges without matching receipts at the top.