Does Order Book integrate with Xero?

No. There is no Xero integration, no app in the Xero marketplace and nothing that connects the two in either direction. You raise the invoice in Xero as you do today, then attach the PDF to the order in Order Book so the café is emailed it and can read it on its own order page. If you want the two joined up, the public API gives you the orders to build from, and that is development work you own and maintain.

Can Order Book issue invoices?

No. It does not create, number, sign, report or send invoices, and it holds no VAT position. It carries the invoice you issued somewhere else: attach the file to the order, the café is emailed it, and it sits on the café's order page next to what was actually delivered.

What does my accountant actually get from Order Book?

A CSV export of every order, one row per order line, with the order number, the client, the status, the dates, the item, the quantity, the unit price, and the order's discount, delivery charge and totals before and after VAT. It opens in Excel, Numbers and Google Sheets. It is a record of what was ordered and delivered, not a ledger: there are no invoice numbers and no credit notes in it.

Can I build my own accounting sync with the API?

Yes, and a few roasteries will. API keys are on every plan and the API reads clients, products and orders and can place an order. There are no outbound webhooks, so a bridge polls the orders endpoint for anything placed since it last looked, and creates the documents on the accounting side itself. Budget for real development time and for maintaining it yourself when either side changes.

Does Order Book take payments from cafés?

No. Cafés pay you the way they do now, by transfer on the terms you set per account. You record what arrived against the client, and the balance shown on the client's page is the value of delivered orders less any credit given on a problem delivery and the payments recorded; a single order can also be marked as paid. Nothing is processed and nothing is taken on it.

How Order Book Works With Your Accounting

Short answer. Order Book does not sync with Xero, QuickBooks, Sage, Holded, Exact, Moloni, InvoiceXpress or any other accounting package. There is no two-way connection and no automatic invoice creation. You issue invoices where you issue them today and attach the file to the order, which emails it to the café and puts it on the café's own order page. What Order Book gives the bookkeeping is the work around the invoice: a delivery note per order, a CSV export of every order line for your accountant, payment terms on each client, payments recorded against the account with a running balance, and a public API if you want to build a bridge yourself.

Does Order Book connect to Xero or QuickBooks?

No, and not partially. There is no connection to authorise in settings, no field to paste an accounting key into, no nightly push, no supported app in anyone's marketplace. Nothing about an order, an invoice or a payment moves between Order Book and an accounting package unless a person moves it.

The tools roasters compare this with do have one, and that is a real difference worth weighing. Orderspace exports invoices to Xero or QuickBooks Online. RoasterTools includes QuickBooks Online sync in its plans and sells Xero as a paid add-on, and its accounting work goes deeper than the word "export" suggests: invoices, payments and payout reconciliation. If invoice sync is the thing that would save you the most time, those products already do it and Order Book does not.

The rest of this page is what a roastery that uses Order Book actually does instead, so you can decide whether the gap costs you an afternoon a month or is a reason to buy something else.

A month in a small roastery, system by system

Take a roastery with 28 café accounts, most of them ordering weekly, so about 120 deliveries a month. Here is where each step happens.

Step	Where it happens	What you do
Prices and per-client catalogs	Order Book	Set once, plus any scheduled change. Nothing to keep in step anywhere else.
The café orders	Order Book	Its own account, its own prices, until the cutoff.
Roast plan, picking, delivery	Order Book	Confirmed orders become the roast plan, the picking list and a delivery note per order.
Raising the invoice	Your accounting or invoicing software	Key it in, from the delivery note or from the export. This is the re-keying.
Getting the invoice to the café	Order Book	Attach the file to the order. The café is emailed it and sees it on its order page.
The café pays	Your bank	Transfer, on the terms on that client's record. Order Book is not in the money path.
Reconciling the bank	Your accounting software	As you do now. Order Book has no bank feed and does not want one.
Recording what came in	Order Book	Enter the payment against the client, or mark the order as paid, so the running balance is right.
VAT return and year end	Your accounting software	Entirely. Order Book holds no VAT position and is not a book of record.

Two rows are entered twice: the invoice and the payment. Everything else happens in one place only. That is the whole shape of the problem, and the section on keeping the double entry small is about those two rows.

What attaching the invoice actually does

On the order there is a place to upload the invoice: a PDF, an image or a spreadsheet, up to 10 MB. The café is emailed in its own language to say the invoice is there, and the link goes to its copy of the order rather than to the file, so it still works in March when a signed file link would have expired. If you replace an invoice with a corrected one, the old one goes with it, so a café is never holding two documents for one delivery and guessing which is current.

That is the part roasteries say they were missing. Not the raising of the invoice, which their software already does well, but getting it to the café and having it sit next to what was delivered instead of in an email thread nobody can find.

What the order export contains

One button gives you a CSV of every order on the book, one row per order line, newest order first. It carries a byte-order mark, so it opens straight in Excel, Numbers and Google Sheets without a character-set dialogue. The columns:

Column	What is in it
order	The Order Book order number. Put this in the reference field of your invoice.
client	The café's name as it was on the order.
status	Placed, confirmed, delivered, cancelled.
source	How the order arrived: the café's account, your desk, a pasted message, the API.
placed_on, delivery_date	The date it was ordered and the date it was for.
item, quantity	The line as the café ordered it, with its quantity.
unit_price	The price that line was sold at, two decimals.
order_discount, order_delivery, order_total	The order's discount, its delivery charge and its total, repeated on every line of that order.
order_net, order_vat, order_gross	The order's money as its page shows it: before VAT, the VAT, and with it. On the order's first line only, so a column sum is the book.
currency	The currency the order was priced in.
note, internal_note	What the café wrote, and what your team wrote. Strip the internal column before you send the file on.

Amounts are in the order's own currency, named in the currency column. The VAT figures are the order's, as Order Book worked them out; the invoice your own software issues is still the legal figure.

What an accountant does with it, in rough order of usefulness:

Check that everything delivered was billed. Filter to delivered orders for the month, compare the count against the invoices raised, and chase the gap. This is the one thing the export catches that nothing else does, and on a busy month it usually catches something.
Build the month's invoices. Filter to one café, and the lines and quantities for its consolidated invoice are in front of you instead of spread across five delivery notes.
Sales by product and by account. A pivot on the item column, or on the client column, without asking you for a report.
Settle an argument. A café says it never had the 6 kg. The row has the date, the quantity, the price and the note.

Be clear with them about what it is not. It is not a ledger. There are no invoice numbers, no credit notes, no opening balances and no journal. It is what was ordered and what went out.

Payment terms, payments and the balance

Each client record carries its own payment terms — prepay, net 7, 15, 30, 45 or 60 — so the terms live next to the account they belong to rather than in someone's memory. When money lands, record it against the client with its date, amount, method and reference, or mark a single order as paid from the order itself.

The balance on the client's page is the value of that café's delivered orders, less any credit you gave when a café reported a problem with a delivery, less the payments recorded against it. Only delivered orders count: a confirmed order the van has not taken yet is a promise, and charging for it would make the balance stop matching the room. A negative balance means the café is in credit.

Say plainly what that is: a running total a roaster would otherwise keep in a notebook, in the place where the rest of the account already lives. It is not a fiscal ledger. No numbering, no VAT position, no ageing buckets, no automatic reminders, no dunning. Your accounting package owns all of that, and it should. For the collecting side of it, see what to do about a café that pays late.

The API, if you want to build the bridge yourself

Every plan has API keys, created and revoked by an admin. A key goes in an Authorization: Bearer header and is read-only unless you give it write access.

Endpoint	What it gives you
GET /api/v1/clients	Your clients, with their payment terms, minimum order, delivery days, cutoff and address.
GET /api/v1/products	What you sell, with sizes, SKUs and base prices.
GET /api/v1/orders?since=…	Orders newest first, with their lines, filtered by timestamp or status.
POST /api/v1/orders	Places an order, priced from that client's own catalog with its case sizes and minimum applied.

A bridge to an accounting package would poll the orders endpoint for anything placed since it last looked and create a draft invoice on the other side. There are no outbound webhooks, so polling is the pattern. There is no invoice object and no payment endpoint in the API, so a bridge can read orders and write orders, and cannot push an invoice or a payment back into Order Book.

Say the cost out loud before anyone starts. This is development work. Someone has to write it, host it, watch it, and fix it when Xero changes an endpoint or your product names change. Nobody at Order Book will maintain it for you. For most roasteries under a hundred accounts it is more expensive than the afternoon of typing it replaces, and the honest recommendation is not to build it. It is there for the roastery that already has a developer and a reason.

Your accounting package, alongside Order Book

A column of "none" is the point of this table. What changes from row to row is only what you do about it.

Package	Integration	What you do
Xero	None	Raise the invoice in Xero from the delivery note, put the Order Book order number in the reference, save the PDF and attach it to the order.
QuickBooks Online	None	The same. If you invoice monthly rather than per delivery, build the lines from the CSV export instead of from five delivery notes.
Sage	None	The same, and check which country edition you are on before you assume anything about its import format.
Holded	None	Raise and send from Holded as now. Order Book holds the copy the café reads and the record of what was delivered.
Exact Online	None	Raise there. Nothing in Order Book needs to know the invoice exists except the attachment on the order.
Moloni, InvoiceXpress or another certified billing tool	None	The legal document is minted, numbered and reported there, under the rules of your country. Attach the copy to the order for the café.
A spreadsheet and an accountant who does the rest	None	The CSV export is the handover. Send it monthly with the internal note column removed.
Anything else	None	If it can import a CSV, the export is your starting point. If it cannot, it is typing.

Where a country requires a structured e-invoice

Several EU countries now require domestic B2B invoices to be exchanged as structured files rather than PDFs, and the list and the dates keep moving. None of that changes anything here. The legal invoice is created, numbered, formatted and reported by your own software, exactly as it is today, and Order Book plays no part in it: it does not number anything, does not sign anything, does not report anything to a tax authority and is not an archive.

The file you attach to the order is the human-readable copy your café reads next to what was delivered. That is a different job from the legal one, and it is the only one Order Book does. If you are working out what your country asks of you and when, start with e-invoicing for coffee roasters.

Is accounting sync coming?

It is not available today, and the honest answer today is no.

There is no date to give you and no roadmap to point at, and you should not buy software on the promise of a feature that does not exist. Decide on what is in front of you: if the gap between the order and the invoice is a real cost in your week, and nothing in this page closes it enough, buy the product that has the integration. That is a reasonable decision and this page exists so you can make it without a sales call.

How much double entry this really is, and how to keep it small

Two things get entered twice: the invoice, and the payment. Nothing else.

Do the arithmetic for your own roastery rather than trusting anyone's estimate. Time yourself keying five real invoices, from the delivery note to sent, and multiply by the number of invoices you raise in a month. For the 28-account roastery above that is 120 invoices a month if you invoice per delivery, and 28 if you invoice each café once a month. The second number is where the saving is, and it costs nothing to switch to.

Five things that shrink the work:

Invoice monthly, not per delivery. One invoice per café per month instead of one per drop. Check your own terms first, tell the cafés before you change, and remember it moves your cash later, which is the real trade.
Build invoices from the export, not from delivery notes. Filter the CSV to one café and one month and the lines, quantities and prices are already in a grid. If your package imports a CSV of sales lines, shape the file once and reuse it.
Put the order number in the invoice reference. One shared number is what lets anyone, months later, line up an invoice against what actually went out of the door.
Record payments in one sitting. When you reconcile the bank, enter the same payments in Order Book while the statement is open, rather than one at a time as they land.
Do not make a second delivery note. Order Book prints one per order. Nothing is gained by producing another in your accounting software, and a café with two documents for one delivery will query the one you did not mean.

After that, what is left is genuinely the typing of the invoice itself, and no honest arrangement of these two systems removes it.

When Order Book is the wrong fit

If you want one system that raises the invoice, chases it and takes the card payment, Order Book is not that system and will not become it on a timescale you should plan around. A general B2B wholesale platform is the right answer, and Orderspace is the obvious one: a proper buyer storefront, stock control, card payments through Stripe, and invoice export to Xero or QuickBooks Online. If your book is mostly production and your bookkeeper wants invoices, payments and payouts reconciled automatically, look at RoasterTools instead.

Some more specific signs that this is not for you:

Your bookkeeper has a veto and the veto is "it must sync". Believe them. They are the one who does the month end.
You raise more than a few hundred invoices a month. At that volume the typing is a job, not an afternoon, and an integration pays for itself.
You need stock control. Order Book counts the roasted stock on your shelf, but it keeps no accounting inventory, and if your accounting package is the stock system too, splitting them will hurt.
You want cafés to pay by card at checkout. Order Book takes no payments at all. Before you build a decision on that, read what card fees cost a roastery — on €40,000 of monthly wholesale it is roughly €1,100 a month, which buys a lot of typing.

What Order Book is for is the other half of the problem: knowing which café has stopped ordering, having the café place the order itself, and turning the orders into the roast plan and the van. If that is not the half that hurts, buy for the half that does.

Questions roasters ask

Does Order Book integrate with Xero?: No. There is no Xero integration, no app in the Xero marketplace and nothing that connects the two in either direction. You raise the invoice in Xero as you do today, then attach the PDF to the order in Order Book so the café is emailed it and can read it on its own order page. If you want the two joined up, the public API gives you the orders to build from, and that is development work you own and maintain.
Can Order Book issue invoices?: No. It does not create, number, sign, report or send invoices, and it holds no VAT position. It carries the invoice you issued somewhere else: attach the file to the order, the café is emailed it, and it sits on the café's order page next to what was actually delivered.
What does my accountant actually get from Order Book?: A CSV export of every order, one row per order line, with the order number, the client, the status, the dates, the item, the quantity, the unit price, and the order's discount, delivery charge and totals before and after VAT. It opens in Excel, Numbers and Google Sheets. It is a record of what was ordered and delivered, not a ledger: there are no invoice numbers and no credit notes in it.
Can I build my own accounting sync with the API?: Yes, and a few roasteries will. API keys are on every plan and the API reads clients, products and orders and can place an order. There are no outbound webhooks, so a bridge polls the orders endpoint for anything placed since it last looked, and creates the documents on the accounting side itself. Budget for real development time and for maintaining it yourself when either side changes.
Does Order Book take payments from cafés?: No. Cafés pay you the way they do now, by transfer on the terms you set per account. You record what arrived against the client, and the balance shown on the client's page is the value of delivered orders less any credit given on a problem delivery and the payments recorded; a single order can also be marked as paid. Nothing is processed and nothing is taken on it.
Is accounting sync coming?: The honest answer today is no. There is no accounting integration in Order Book and none you could buy on the promise of one, so judge it on what it does now. If a sync is what decides the purchase, a general B2B platform such as Orderspace already has one and you should buy that instead.

Where Order Book fits

Order Book runs the wholesale desk: the price sheet, the café's own ordering account, the cutoff, the drift on an account that has gone quiet, the roast plan and the delivery note. Your accounting software runs the money: the invoice, the VAT, the ledger, the year end. The seam between them is two pieces of typing a month and an attachment on an order, and this page has told you exactly how much that is so you can price it against what you would pay elsewhere.

If that seam is acceptable, the fastest way to find out is on your own book: import your clients and history, invite one café to its account, and see what the first week looks like.

Start free for 30 days, no card, or see what it costs.

How Order Book works with your accounting