# Month-end close without chasing receipts

> Every Atta order gets its own card capped at the approved amount. Budgets follow settled payments and each invoice links to the PO it names. CSV on demand.

Updated 2026-11-06. Source: https://atta.sh/use-cases/month-end-close

Atta pays each order with its own single-use card, capped at the approved amount. A second charge, a larger one or one from another store is declined. Budgets count an amount as committed when ordered and spent when payment settles, and each invoice is matched to the purchase order it names.

## One card per order

When a workspace has a card program on, placing an order issues a virtual card for that order only. It's capped at the reserved total on the card issuer's side too, so the limit holds even if our code was wrong.

Take an order of $698 for two chairs. The card's charges:

| Charge | Amount | Result | Reason |
| --- | --- | --- | --- |
| Office supplier | $698.00 | Approved | The approved payment |
| Office supplier | $698.00 | Declined | Already paid, and the card is single use |
| Another store | $120.00 | Declined | The merchant's network id differs from the one pinned on the first approved charge |

A merchant name that only looks different, because a processor rewrote the descriptor, is flagged to owners and admins and not declined. The real-time answer comes from a pure function with zero tolerance. It isn't a second policy. The number and CVC never enter the app. A person sees them in the issuer's own frame.

## Committed, then spent

A checkout reserves the amount against the budget. A reservation is not a payment.

- **Paid** keeps the reservation, and the amount counts as spent.
- **Cancelled** gives it back.
- A payment that arrives after a release holds the money again under a late-payment entry.
- If the store's total differs from the row's total, the difference is logged. Above the row's total, the difference is held too.

For a card order, the card's own events are the only thing that moves the budget. The store's webhook moves the order's status. Nothing decrements a budget on the assumption that a handoff was a payment.

## Sweeping what nobody answers

Two buttons on the orders page mark a checkout paid or cancelled, for a store that never sends a webhook. An hourly sweep releases checkouts nobody answers. 

## Invoices

A received e-invoice links to a purchase only by the PO number it names, first BT-13 and then BT-10, never by supplier alone. A matched invoice becomes that request's invoice row. An invoice that names no PO we know stays unlinked. See [e-invoicing](https://atta.sh/e-invoicing).

## What finance gets

Each request carries who asked, who approved, what it cost, the cost centre and GL code, and when it was paid. Tables filter and sort on the server, and a filtered view is a link you can paste. CSV exports are built on the server from the same query, with the same redaction a viewer sees on the page.

Cells starting with `=`, `+`, `-` or `@` are prefixed so a spreadsheet won't run them as formulas.

## Where it fits

It works for teams where the agent pays with a card. Without a card program, Atta builds the cart and hands over the checkout link, and the budget settles from the store's webhook.

Atta is in invite-only beta and free during the beta.

## Questions

### What happens if a merchant charges the card twice?

The card is single use. The first approved charge closes the order, and a second is declined in real time.

### When does a budget count an amount as spent?

An amount is reserved when the order is placed and counts as spent when payment settles. A cancellation releases the reservation.

### How are invoices matched to orders?

By the PO number the invoice names. Atta doesn't match on supplier alone, so an invoice with no recognized PO stays unlinked.

### Can I export spend for my accountant?

Yes. Tables export CSV from the server using the same filters and redaction as the page, with the cost centre and GL code on each request.