On this pageCode it when it happens
The close is slow for one reason: information that existed when the money moved — which agent, which project, which customer — has to be reconstructed weeks later from an invoice that does not contain it.
Code it when it happens#
Every Nebula card is bound to an agent, an environment and, optionally, a project and a customer. When it is charged, those dimensions are written to the ledger line immediately. There is nothing to code later because nothing was left uncoded.
For vendors billed outside a card — a monthly cloud invoice, say — connectors read the usage export and split the bill along the same dimensions using the tags you already put on resources.
Receipts that match themselves#
Receipts are fetched from the vendors that publish them and attached to the matching line automatically. For the rest, the cardholder — human or agent — gets a request at the time of purchase, not at month end.
| Step | Before | With Nebula |
|---|---|---|
| Code vendor lines | 2–3 days | Done at authorisation |
| Collect receipts | 1–2 days | Attached automatically |
| Reconcile to bank | 1 day | Continuous |
| Review and export | Half a day | Half a day |
An export your accountant accepts#
The close ends with a journal export mapped to your chart of accounts. We support the major general ledgers directly and a plain CSV for everything else. Mapping rules are set once, during onboarding, and reviewed rather than rebuilt each month.
Keep the review step. Automation removes the busywork; it does not remove the need for someone to look at the numbers before they are final.
What is left for people#
With coding and matching handled, the close becomes what it should have been: reviewing anomalies, deciding accruals and explaining the month. That fits comfortably in an afternoon.