Your cloud contract renews on Monday and a large customer renews on Tuesday. The vendor charges the company card immediately and then emails an invoice anyway. The customer’s procurement team still needs a new PO before it will accept your invoice. By Friday the vendor invoice is sitting in AP as an open bill, your renewal invoice has been rejected by the customer’s portal, and the bank shows a processor deposit that is $50 short of what billing says it collected.
None of these is hard on its own. The trouble is that AP, AR, and cash all move in the same week, through card feeds, portals, and processors, and all three land in the same close.
Put both sides of renewal week on one calendar
Vendor and customer renewals can land in the same week. Track them together, but keep separate dates for when money leaves and when it can come in.
| Event | What finance confirms | Who owns the next step |
|---|---|---|
| Vendor renewal notice date approaches | Keep, resize, or cancel under the contract terms | Department owner |
| Vendor charges the card | Which contract the charge covers and whether the invoice is already settled | AP or card reviewer |
| Customer renews with more seats | Signed amendment, effective date, updated PO if required | Account owner and billing |
| Customer invoice reaches the portal | Submission reference, acceptance, or rejection reason | Billing |
| Customer pays | Bank date, remittance, and the invoices it covers | Cash application |
Keep the contract and invoice references on each row. The vendor’s notice date matters more than its invoice date: by the time the bill arrives, the window to cancel or downsize has usually closed. In the cash forecast, use agreed due dates and confirmed payment schedules, and label estimates as estimates.
Vendor side: SaaS subscriptions and card-paid invoices
The SaaS payables error to design against is paying twice. A vendor charges a company card, then sends an invoice to the AP inbox. The department recognizes the subscription and approves the invoice. If AP creates an open bill from that approval, the next payment run pays a charge the company already settled.
Check card activity and vendor payment history before creating a payable. Compare supplier, billing entity, currency, amount, and invoice reference. A same-amount charge from the same supplier might be a different subscription, so when the match is uncertain, show the card line and the invoice side by side to a reviewer rather than auto-matching.
- Invoice already settled by card: attach the document to the existing card transaction, or record it through your approved workflow as a bill with its payment. Do not leave an open bill.
- Invoice unpaid: route through normal approval.
- Bill first, card charge later: AP needs to see the new card line before the bill is selected for payment. Test this order explicitly; it is the one that slips.
The duplicate payments guide covers vendor master controls that make these matches more reliable.
Separate the renewal decision from invoice approval
Invoice approval is the point to compare the bill with the decision the owner already made, not the moment to make the decision.
| If AP sees this | Send the reviewer |
|---|---|
| Renewal includes more seats than approved | Order form, approved seat count, and invoice lines |
| Vendor changed the billing entity | Contract entity, invoice bill-to, and vendor record |
| Annual invoice includes a partial-period adjustment | Prior bill, change date, and new coverage dates |
| Owner has left the company | Named backup and the contract awaiting a decision |
If you spread annual software costs over the service term, capture the coverage dates at review. The invoice date cannot tell accounting which months the service covers. The prepaids and accruals guide shows how to build the schedule from those dates.
Vendor side: cloud and AI usage bills
A cloud bill can rise because your customers used more of the service, a committed-use discount expired, a credit did not appear, or a charge belongs to another account. Each has a different owner. Route the bill to the person who can explain the change, with the billing period, account, prior period, and cost detail attached.
Work through it in order:
- Match the scope. Billing account, service, period, and currency. A shared account can include usage owned by several teams.
- Separate quantity from rate. Compare units with the previous period and check the billed price against the contract or rate card.
- Verify commitments and credits. Which charges qualify, when the terms took effect, and whether the expected credit is on the invoice.
- Ask the owner about what remains. Give engineering the service and usage details. Give procurement the rate, contract reference, and amount in question.
AWS shows invoice details including the billing period and consolidation account alongside payments and credits (AWS Billing payment information). For service-level detail, AWS documents Cost and Usage Report fields such as usage type and resource ID, using DynamoDB as an example (AWS DynamoDB billing guide). Use whatever fields your own export carries to narrow a charge to the resource that generated it.
Illustrative example: splitting a cloud variance
One service line went from $10,000 to $12,650. The usage export and rate card show:
| Units | Rate | Charge | |
|---|---|---|---|
| Prior month | 200,000 | $0.050 | $10,000 |
| This month | 230,000 | $0.055 | $12,650 |
- Quantity effect at the old rate: 30,000 × $0.050 = $1,500
- Rate effect on this month’s units: 230,000 × $0.005 = $1,150
- Total: $1,500 + $1,150 = $2,650
Engineering explains the $1,500. Procurement explains the $1,150: either the contract allowed a price change, or a committed rate lapsed and you have a claim. Record the line, source usage, expected charge, and reason for any difference with the bill. If you dispute a charge, keep the supplier’s response with the original invoice and check at the next bill whether the promised credit arrived.
If finance allocates a shared bill across teams, save the allocation basis with the entry and keep the supplier total visible so a reviewer can tie the allocated lines back.
Customer side: route unpaid invoices by cause
A failed card charge and a rejected enterprise renewal both show up as unpaid. The card customer needs a link to update a payment method. The enterprise customer may have approved the renewal but cannot accept an invoice without a new PO. Send both the same reminder and neither gets what it needs.
| What happened | First action | Who takes over |
|---|---|---|
| Recurring card charge failed | Read the failure reason; check whether a retry is allowed | Billing support if a new payment method is needed |
| Customer portal rejected the renewal invoice | Show the rejection reason and current PO or billing instructions | Billing, with the account owner |
| Customer disputes a mid-cycle charge | Pull the invoice lines, contract change, and effective date | Billing and the account owner |
| Bank deposit with no usable reference | Review payer, amount, currency, and open invoices | AR |
| Processor payout lower than gross collections | Trace fees, refunds, and timing to the payout detail | Accounting |
Stripe’s invoice reference says an invoice with a non-retryable payment failure needs a new payment method before another attempt can run (Stripe invoice object). Make the customer message ask for the action that can actually resolve the failure.
Status matters too. In Stripe, an invoice stays in draft until finalization, after which it can be sent or paid (Stripe’s invoice documentation). Check the status before treating a renewal as issued, then confirm customer acceptance separately if the customer uses its own procurement portal. Stripe’s invoice object also exposes the error from the last failed finalization (Stripe invoice object), which gives billing a starting point before collections gets involved.
When billing corrects a rejected invoice, check which record is collectible and whether the original still sits in aging. Resume follow-up only once the replacement is accepted. Charge-level accuracy checks are in the SaaS billing accuracy guide; portal and PO requirements are in the invoice acceptance guide.
Cash: follow a processor payout into the ledger
The bank shows a $950 deposit. Billing shows $1,000 in customer payments. Before calling it missing cash, open the payout detail. In this illustrative case, a $30 refund and $20 in fees explain the difference: $1,000 − $30 − $20 = $950.
Stripe’s payout reconciliation report is designed to reconcile a payout with the batch of transactions it settles (Stripe payout reconciliation report). Identify the deposit by payout ID, currency, and bank account, then pull the charges, refunds, fees, and adjustments in that payout.
| What you see | What to confirm |
|---|---|
| Customer charge | Which invoice it settles and that AR shows the application |
| Refund | Original charge, approved refund, and any related credit |
| Processor fee | Amount and the expense account your policy uses |
| Payout | Net amount, bank account, and clearing date |
| Amount in transit | Transactions not yet at the bank and the payout that will clear them |
Using a processor clearing account keeps this tidy. Illustrative entries for the payout above:
| Entry | Debit | Credit |
|---|---|---|
| Charges captured | Processor clearing $1,000 | Accounts receivable $1,000 |
| Refund issued | Refunds (per policy) $30 | Processor clearing $30 |
| Fees deducted | Processor fees $20 | Processor clearing $20 |
| Payout lands | Cash $950 | Processor clearing $950 |
Clearing nets to zero: $1,000 − $30 − $20 − $950 = $0. At month-end, whatever remains in clearing should equal transactions captured but not yet paid out. If a charge and its refund settle in different payouts, carry both references so the reviewer can explain the timing. Check that importing the same payout twice does not create a second deposit. The bank reconciliation guide covers the statement side.
Test software on your own problem records
A clean sample invoice tells you little. Use two records your team has already struggled with:
- A cloud bill you disputed. Provide the contract or rate card, usage export, and invoice. Mark one line where usage agrees and the rate does not. Can the tool trace that charge to usage and rate, or does it just extract the total?
- A customer invoice that was rejected for a missing PO or wrong billing entity. Mark the rejected field and where it should have come from (contract, CRM, or billing system). Ask to see the check run before the invoice goes out.
If a demo cannot trace either discrepancy to its source, that investigation stays with your team. The buying guide has a fuller test plan.
Measure the queue you changed
| If you changed | Track |
|---|---|
| Card retry logic | Failed charges recovered vs. those needing a new payment method |
| Enterprise invoice submission | Days a rejected invoice waits for correction and acceptance |
| Cash application | Days receipts stay unapplied; how often AR reverses a match |
| Vendor bill intake | Card-paid invoices caught before entry; bills waiting on an owner |
Compare like with like. A shift from annual contracts to monthly card billing changes DSO even if the collections process stays the same.
Four checks for the SaaS close
- Check every vendor invoice against card activity before a bill is created
- Split each cloud variance over your review threshold into quantity, rate, and credit
- Tie the processor clearing balance to transactions captured but not yet paid out
- Pause reminders on invoices with a confirmed but unapplied payment