The month-end export routine
This is the page for six o'clock on the last day of the month. It sets out a routine you can run in order, with the awkward parts named, so that nothing is discovered at nine the following morning by somebody else.
The shape of it is the same whether you post to QuickBooks Online, to Xero, to both, or export a CSV. The five questions the routine asks are: is anything still waiting on a human to read it, is anything waiting on a decision it should already have had, has everything approved been sent, did everything sent actually land, and can I answer the questions I will be asked about it.
Before you start
- Roles. Running an export is an Admin or Controller Approver action, and so is retrying a failed batch. Anyone may read the Exports screen and the audit trail.
- A destination. Either a connected ledger with Post approved bills here switched on, or a CSV mapping you are happy with. A ledger that is connected but not switched on receives nothing, and the screen says so above the button.
- Time before your own deadline. Nothing in this routine is instant, and step 4 can send you back to step 1 to fix an invoice.
- Know what will not happen. inletAP does not move money and does not close a period. See the last section before you promise anybody otherwise.
1. Clear the review queue
Start with the invoices that need a person. Anything read below the review threshold routes to Review Queue, and so does an invoice whose property evidence was too weak to code on and a file we could not convert or read at all. Quarantined files sit in their own state rather than in this queue, and an unmapped vendor or line items that will not add up are caught later, at export.
Two other piles are easy to forget, because neither is in the review queue.
- Filtered messages. Anything judged not to be an invoice — newsletters, auto-replies, bounces, calendar invitations — is set aside before extraction, so it never costs quota. It is not deleted: it sits under the Filtered tab of the Inbox with a count beside it and a restore action on each row. Skim it once a month and restore anything that was a real invoice with an unusual covering note.
- Held invoices. On a paid plan, invoices beyond your allowance are processed and charged at the overage rate. On the Free plan the cap is hard: extra documents are held, parsed but not extracted, and released when you upgrade or the period rolls over. Month end is when a busy month becomes visible, so check the count before you assume the queue is empty.
2. Chase the approvals that are late
Open Approvals. The queue groups by how much time is left, in this order: Overdue, Due within 4 hours, On track, and No deadline for invoices that have no clock on them at all. Work down from the top.
An invoice waiting on a two-approver tier shows how many signatures it has, and the person who gave the first one cannot give the second. If your controller is unreachable, an admin can decide an unaddressed approval — which is the intended safety valve, and is recorded as exactly that in the audit trail.
Two things this step will not do for you. Nothing approves itself when a deadline passes, and nothing escalates to another tier. An overdue approval is a measurement, not a mechanism. If you find yourself clearing the same overdue tier every month, the tier is wrong rather than your team, and approval tiers explains how to change it.
3. Export the batch
Open Exports. The button at the top names what it is about to do — Post approved to 2 ledgers, or Post approved invoices when there is one — and pressing it takes every approved invoice not already claimed by a batch for that destination. You do not select rows, so you cannot miss one that arrived while you were reading the list. One exception: an approved invoice that Second Look has flagged as a hard duplicate is held back until somebody answers the card on it, and it goes out in the next batch.
A CSV is a separate act: press Export as CSV. It is not what happens automatically when no ledger is connected. The same document can go to a CSV batch and to a ledger batch, because those are different destinations; it cannot go twice to the same one.
Pressing the button twice creates one batch — the second request waits, re-reads and finds nothing left to claim. This is more interesting than it sounds, since the alternative is a vendor being paid twice.
You should now be looking at a new run at the top of the export history, holding one batch per destination, each moving through pending, processing, and then succeeded or failed, independently of the others.
4. Check what posted, and what did not
Open the batch. Items needing attention are sorted to the top, each with the reason and the next move.
| What you see | What it means |
|---|---|
| A held item naming a vendor or GL code | It is not matched to your ledger yet. The bill has nowhere to post. Match it, then retry the batch. |
| A held item naming the arithmetic | The line items do not add up to the invoice total, or stated tax has no tax code. Open the invoice and fix the figures. |
| A refusal from your ledger | The ledger declined the bill. In QuickBooks the commonest is a bill it already holds with that invoice number. |
failed_export on a document | The attempt failed and the document is waiting to be sent again. |
Retry once the underlying cause is fixed. Retry the whole batch works on the whole failed batch rather than on one row, and Retry the whole run re-queues only the failed batches of a run — a ledger that already took the bill is not asked again. Either replays the same logical posts rather than creating second bills, and anything already in your ledger is skipped, so both are safe to use even when you are unsure what got through.
One cause is not a ledger refusal at all: a row that starts no_default_ledger, unrouted_entity or not_entitled never reached a ledger. It is waiting on a switch in settings rather than on anything about the invoice. Export failures has the three and their fixes.
Exports that finish in a state a human should look at also send one email to the members who have that notification switched on, which is useful if your close runs past the point where anyone is still watching a screen.
5. Reconcile, which is the step that proves it
On a paid plan, reconciliation reads back what you posted and compares it against what the ledger is actually holding — over a thirty-day window, which covers a monthly close comfortably. It is the only step that verifies an export rather than trusting a success response, and it is where you find the bill an accountant deleted or edited a fortnight ago.
Start it from Settings → Connectors, after your final export rather than before. It is read-only: nothing is written back to your ledger.
If your plan does not include it, the honest substitute is narrower: every exported document records the external ID the ledger gave back, so you can open any invoice and answer "where did this end up" one document at a time.
6. Answer the questions from the audit trail
The questions arrive later, and they are always the same three: who approved this, what did it say before somebody changed it, and why did this one go through automatically.
The Audit Log answers all three. Every state change is recorded with the actor — a person, the system or a rule — a timestamp, and the value it holds now; a field edit also records the value it held before, so a corrected total reads as $3,500.00 becoming $4,000.00 rather than as $4,000.00 with no history behind it. Field edits, rule matches, routing decisions, approvals with their comments, rejections with their reasons and the successful export of each document are all there.
So are the export failures and the retries: a bill that stops without reaching your ledger writes export.failed, naming the batch, the destination and the reason the ledger gave, and pressing Retry writes export.retried against the person who pressed it. One deliberate exception: a bill your ledger already holds writes no failure event, because it posted. The Exports screen is still where you act on a failure — the per-invoice reasons and the retry buttons are there — and the trail is where you read afterwards what happened and who acted. It is append-only: no role has an edit or a delete path, including yours.
You can filter the trail by actor, by action and by whether the change was made by a person or by automation, and export what you are looking at as a CSV to attach to a close file. The field source is recorded too, so "this GL code came from a rule" and "this GL code came from the page" are different answers rather than the same one.
What month end does not include
inletAP does not move money. There are no ACH or check rails; approved bills land in your ledger and payment happens wherever it happens today.
Nor is there a period close. Nothing locks, nothing rolls over and no journal is posted on your behalf. Your ledger owns the close; inletAP owns getting the bills into it, coded and approved, before you start.
Where to go next
- Exports reference — runs and batches, statuses, CSV columns and retries.
- Export failures — the causes, in the order worth checking.
- Audit trail — what is recorded and how to read it.
- Approval tiers — for when step two is always the slow one.