What your accountant needs at month end, and where the time goes

The handover is the statement that never arrived, the row nobody can explain, and the month that changed after they had started on it. None of it is accounting, and all of it is billed at the accountant's rate. Each has a fix on your side of the desk, and each fix starts with knowing what their system accepts.

Two doors, not one

An accounting system takes a period through two different doors, and knowing which is which saves the first email.

Journal lines are the accounting itself: for every movement, what it was and which account it went through, as a debit and a credit that sum to zero. QuickBooks Online imports them as a CSV under Settings, then Import Data, then Journal Entries, and asks for a journal number, a journal date, an account name, a description, a debit and a credit column; its help page tells you to "Turn off account numbers before you begin" and to name a sub-account as "Parent account: Sub Account". Xero's manual journals work the same way from the other end: on each line "Debits are positive, credits are negative value", every journal carries a narration and a date, and a journal needs at least two lines.

Bank statement lines are the bank's side of the same month: what moved, when, for how much, with no opinion about what it was. QuickBooks takes them under Bank transactions, "Upload from file", as a CSV with either three columns (Date, Description, Amount) or four (Date, Description, Credit, Debit), "in English and 350 KB or less", with every date in one format. Xero's bank reconciliation page says the plain thing: "If your bank doesn't connect to Xero, you can manually import your transaction data." The accountant then matches those lines against what is booked, and in QuickBooks reconciles the account by typing the "Ending balance and Ending date from your account statement" and matching until the difference is zero.

Which door does your accountant want? Usually both: the journal to book the month, and the statement lines to prove the journal against the bank. A folder of PDFs is neither; it is raw material for someone to type.

In Orla the month leaves through both doors at once. The journal is a CSV of double-entry lines that Xero and QuickBooks import, two lines per transaction, with the amount that moved in its currency, the value in your base currency at that day's rate, and the rate itself, so every line reconciles on its own. The statements come one file per account, because both systems import a statement into one bank account, in the shape QuickBooks Online expects (Date, Description, Amount, money out negative) or the shape Xero expects (Date, Amount, Payee, Description, Reference), with your category riding along in the description as a hint. There is no Xero or QuickBooks login to connect; the handoff is a file.

What they need before they can book anything

Ask any accountant what stops them on day one and the list is short and always the same.

Every account that moved, with its closing balance. Not the main account: every one. The second bank, the Wise balance, the card, the sales platform, the wallet. The account you forgot is the account they will email about.

Every row with a code, not a category name. Your categories are yours. Their chart of accounts has codes, and the same number means different things at different companies, which is why Orla never guesses one. Every category and every account gets the code it books to, entered once and reused every period; archived accounts and old categories stay on the list because past periods still need them. A period with a code missing or a row uncategorised does not export at all. The screen lists exactly what is missing and how many rows each gap covers, because a file that quietly books half a month to nowhere is what the accountant discovers weeks later.

The paper. The receipt behind the expense, the supplier's bill, the invoices you issued. Not because the accountant reads them all, but because the one they need is the one that is missing.

Who signed the payments. For a company with approval rules this is part of the record: who proposed, who signed, when it left, what the bank or the chain gave back.

The crypto arithmetic, already done. A coin sold, swapped or spent came from lots bought at some price, and the accounting system never saw those lots. The realised gain or loss has to arrive computed, on its own line, or the accountant rebuilds it in a spreadsheet at their rate.

A month that has stopped moving. Nobody can book a period that is still being edited behind them. Both systems have their own lock for this: QuickBooks Online has "Close the books" with a closing date and an option to require a password for changes before it, and Xero keeps lock dates on the organisation and, since March 2025, a reconcile period that can "protect the transactions for the period from being changed" once it balances. Those locks protect their book. Yours needs one too, on the side the rows come from, which is what a month-end close is for.

The mapping is one conversation, once

The chart-of-accounts mapping is the only part of this that needs the two of you in the same room, and it happens once. Send the accountant your category list and the account list, get back a code for each, type them in. In Orla this is the Chart of accounts tab beside the months on For the accountant; the tab shows how many codes are still empty, and the month's checklist points at a missing one and opens the tab. The codes can also be typed in conversation: "the code for Marketing is 6200" saves it, and the assistant never invents one.

Two lines people forget. "Realised gain or loss on crypto" is on the list with everything else and needs a code before the first disposal exports; a disposal with no code stops the export the same way a missing category code does, because dropping the third line would hand over an entry that does not balance. And the accountant can do this themselves: the Accountant role, on Pro and above, fills in codes and downloads the journal and the archive, and cannot pay anyone or edit the ledger directly. Their seat never takes one of your seats.

The checklist to send with the files

Copy it into the email, or into the note on the month. Every line is a question the accountant would otherwise ask.

1. Period: which month, and whether earlier months are closed.
2. Files: the journal, one statement per account, the ledger with every column, the payments with signers, the invoices issued, the crypto disposals by lot, the VAT summary if you file one.
3. Per account: which accounts moved, and the closing balance on the last day.
4. Gaps, named: receipts missing (how many), bills still open, client invoices still open, currencies with no rate on some day.
5. What changed since last time: any earlier month reopened, any rule for sorting rows created or changed this month.
6. How the rows were sorted: how many by a rule, how many by the merchant dictionary, how many by hand.
7. Who answers questions, and by when you need the month back.

In Orla the archive writes most of this for you. Its README says what is inside and why anything is missing, and how the month was sorted, in words like "183 by a rule you wrote, 40 by the merchant dictionary, 12 by hand", how many rows a connected agent wrote, and which rules were created, changed or deleted inside the month, with the date and who did it. The same counts are on the page before you download, under Check the month. A month whose journal is not ready still ships as an archive, with a text file naming the gaps instead of a half-journal, and its name says so ("without the journal, N gaps").

Where the hours go

Four places, in the order they usually cost you.

The account nobody filed. The accountant has the main bank and not the Wise balance, or the card but not the wallet. Orla's month checklist asks that every bank, card and platform account that moved has a statement filed for the month, and compares each statement's closing balance with the book on the month's last day; for a synced account without a statement it compares the provider's movement with what the book explains. That check goes into the record rather than blocking the close, but it is the first thing to read before pressing Close.

The row nobody can explain. Row 213, "TRANSFER 4471", 840 euros, no receipt, no category. Multiply by thirty. The fix is upstream of the handover: rules on import for recurring payees, the merchant dictionary for well-known ones, receipts asked for the week the expense happened with reminders on the third and the seventh morning, and an honest "no paper for this one" that removes the row from the list for good. The README's sorting counts then answer the accountant's real question, which is not "what is row 213" but "how much of this book did a person actually look at".

The month that moved. The accountant is halfway through August when somebody edits a July row, and now their July does not match yours. Orla's month can be closed: once nothing blocks, Close seals it, and adding, editing or deleting anything dated inside it is refused with the month named and the way to reopen. Only an owner or admin can reopen, with a reason, and both are recorded. The archive stamps a fingerprint of the month when it is downloaded, and a row added, edited or deleted afterwards turns the month into "changed after the handoff", so the accountant is sent the month again instead of working from a stale file. Background bank and exchange syncs still write, so a closed month can drift and then says so. Ask "which months changed after I sent them" and the answer is the list.

The crypto arithmetic. A transfer between your own wallets booked as a sale and an income, a network fee that never reached cashflow, a disposal with no cost. This is the part accountants quote extra for, and it is the part the archive carries already done: the disposals by lot with cost basis, proceeds, gain, holding period and the on-chain hash, and in the journal the sale as three lines, proceeds, cost basis leaving the books, and the realised gain or loss on its own. A currency with no rate on some day still exports, with the amount that moved and an empty base-currency column, because nobody can supply a rate that does not exist; the screen names the currencies so the empty column is not a surprise. Contractors paid on two rails add their own lines to this, and paying contractors by bank and in USDC from one book walks what each rail leaves.

What the accountant still does

Everything above gets them to the starting line faster. It does not move the line. Adjusting entries, accruals, depreciation, the tax treatment of a payout, whether a contractor is a contractor, whether a stablecoin disposal is taxable in your country: all of that is theirs. The reconciliation itself happens in their system, against the statement lines you sent. Orla does not sync with QuickBooks or Xero and does not post anything into them; the accountant imports the file, maps the columns, and decides. Xero's own year-end guidance says "You don't need to do a formal year end close or roll-up journal in Xero"; what it asks for is reconciled bank accounts and reviewed reports, and that is what the handover is for.