Multibook sync#

Getting There#

Go to Settings → Multibook sync, or click Multibook sync at the top of Settings → Multibook. Like the Multibook settings, it only appears once the company is connected to Multibook.

Sync now#

The Sync now card at the top is the only place a person starts a sync with Multibook. Its header shows when the last sync ran, who started it and how it ended, and the Sync now button says how many steps are ticked. The Chart of Accounts, Journal Vouchers and Multibook business partners pages no longer have their own sync buttons; they link here instead (Open Multibook sync). It lists the module syncs in dependency order, grouped so that steps that do not wait for each other sit together, with journals last. All of them are ticked by default.

The ten steps sit in six groups, shown as Group 1 to Group 6. Steps in one group do not wait for each other; a step only needs the groups before it: employees and purchase orders need the partners (and the items), goods receipts need the purchase orders, invoices need the chart, partners and items, collections and payments need the invoices, and journals come last because every document step adopts the journal it posted first.

The Employees, Purchase orders, Goods receipts and Collections and payments rows follow the same pattern as the others: a note when rows are waiting for something to reach Multibook first, hints from the readiness check, and View report after the run listing what could not be sent and why (a supplier or item not linked, no site or storage place, no rate, a purchase order that is not in Multibook yet, a fund account not linked to a Multibook bank account, and so on). The goods-receipt and collections steps share the journal step's Start date, which is the date from which Multibook posts those journals. Multibook-made purchase orders and receipts are listed for visibility only; they never become ANTE purchase orders.

When a company connects with history, the invoices go up first and the collections, payments and credit or debit note applications ANTE already holds against them are queued right after, whatever their date, so a paid invoice is cleared in Multibook instead of staying open there. Until they are sent, Collections and payments shows how many invoices are still open in Multibook while ANTE shows them settled; the count drains on its own as the clearings send, and asks you to run the step or switch its sending on only when nothing is queued.

Untick what you do not need; an unticked step fades so the selection is easy to read. Ticking a step also ticks the steps it needs first and says so, for example Also ticked Chart of accounts — Invoices needs it first; a step is disabled only when something it needs cannot run at all, and it then says why. A step that setup is blocking shows the reason instead: Multibook is not connected (Connect Multibook under Settings → Cloud Credentials first), calls are paused by the administrators, or the journal document type is not chosen (Choose the journal document type in Settings → Multibook first). Each row shows, on the right, when it was last synced and, when items are stuck, an N need attention link to the module page; a Blocked or Needs an earlier step badge appears only when the step cannot run. Hints can appear and the step still runs: the partner customer and vendor categories are not set — when Multibook's own partners show which categories its customers and vendors use, the step fills the empty fields with those and says so (Settings → Multibook keeps them, and you can change them there); only when nothing can be derived do new ANTE clients and suppliers stay uncreated in Multibook until you choose the categories — the company write key is missing (system postings such as payroll and reimbursements cannot be sent, and ANTE-only accounts cannot be created in Multibook), chart push is off (ANTE-only accounts will not be copied up), or GL posting roles point at accounts Multibook does not have.

The Journal entries row has a Start date. It defaults to two years back, so the last two years of journals are covered; a note under it shows the date earlier runs already reached, and a run from an earlier date extends that. If some of those vouchers post to accounts that exist only in ANTE (Multibook never had them), the preview says how many will not be sent, and a hint names the GL posting roles that point at such accounts — fix those in GL account mapping first. Beside it, a highlighted box shows how many posted vouchers from that date will be sent, and how many of them are system postings. Before the first journal sync a warning reminds you that vouchers also entered in Multibook by hand will be counted twice; start from the date you stopped doing that. A Reimbursement claims note under the steps explains that claims are not a step: each one goes to Multibook on its own when it is approved, and is retried from the claim.

The Reference lists step depends on nothing and nothing waits on it: a failed or paused read never stops the chart, partners, items, invoices or journals. They simply keep using the lists read last time. Before a list has ever been read, a warning in the readiness panel says so and Settings fields accept a typed code. The same lists are also refreshed on a schedule and with Refresh under Settings → Multibook → Your Multibook company.

Journals and invoices are also checked against Multibook's open posting periods before they are sent. A document dated in a closed period is not sent and is not an error: it waits, shown as Waiting for Multibook period FY2027-1 to open, and goes up by itself once the Multibook administrator opens that period. An invoice whose number Multibook already holds for the same partner is listed under the invoices that cannot be sent, because Multibook refuses repeated invoice numbers.

If an item could not be created, updated, deleted or restored in Multibook, the item list header shows Review sends (and the Items step's N need attention opens it): each failed item is listed with the reason and Retry or Discard, and links to the item.

The Items step depends on nothing, so a failed item sync never blocks the chart, partners or journals. When some ANTE items have a unit Multibook does not know, a hint says how many will not be created in Multibook until a Default unit is chosen under Settings → Multibook. After the step finishes, View report shows what was linked or created, and the Multibook items that were held for a decision, each with the reason: the ANTE item with that code is deleted, it is an item group, two Multibook codes differ only by upper or lower case, or the code cannot be an ANTE SKU. Open the item list to resolve them.

The Invoices step runs after the chart, the partners and the items, and shares the journal step's Start date (the date field shows when either step is ticked). It needs the chart, the partners and the items. Hints can appear and the step still runs: no customer or vendor invoice document type is chosen, no default site is set, or the tax-code map is empty for a tax type that waiting invoices use. All of these are fixed under Settings → Multibook. A muted line counts older invoices that already went up as journals; they stay that way and are never sent twice. After the step finishes, View report lists the ANTE invoices that could not be sent, each linking to the invoice with the reason (the client or supplier is not linked to a Multibook partner, a line's item has no Multibook code, no Multibook tax code for the tax type, no default site or document type, an account missing in Multibook, no booking rate on a foreign-currency invoice, or no lines), the Multibook invoices held for a decision (the partner or an item is not linked, a Multibook tax code is not mapped to an ANTE tax type under Recognise on import, the document is a credit or debit memo (ANTE has no credit / debit notes yet, so it stays in Multibook only), financial amounts differ from the ANTE copy, the period is closed, or the invoice was reversed in Multibook), and counters for invoices brought in, matched to journals already imported, sent earlier as journals, and reversed in ANTE.

A step can also read Waiting with a note such as 12 rows are waiting for their dependencies to reach Multibook. That is not a failure: a journal or invoice is held back for a few minutes until the customer, supplier or item it needs has been created in Multibook, then it goes up by itself.

On the document itself (an invoice, purchase order, goods receipt, collection or payment) the same wait shows as a blue Waiting for ... badge and a Waiting to be sent to Multibook notice that names the reason and since when, instead of a bare Sending. Nothing is wrong and nothing needs doing; View details lists it with the other pending sends.

Readiness#

The Readiness panel, at the top of this page and of Settings → Multibook, says whether each step can run and what to fix first, before you click Sync now. It is checked against your settings and what ANTE already holds; it never contacts Multibook. Each step shows a state: Ready, Needs attention (it runs, but part of it will fail or wait), Blocked (it cannot run), Waiting, Paused (an administrator switched it off, or ANTE paused calls to Multibook) or Off. Under a step, each issue is one line with how many rows it touches and a button that takes you to the fix: Open settings goes to the right card of Settings → Multibook, Go to the step to the sync step that must run first (for example business partners when invoices wait for an unlinked customer), and Link my account to My Profile → Connections when rows wait for a person to link their own Multibook sign-in. Problems that belong to no single step, such as Multibook not being connected, are listed once at the top. A code you saved in Settings that is no longer in Multibook's list is reported here too, with the setting and the code. Rows parked because Multibook's posting period is closed are counted, and the dialogs that list unsent journals and invoices show them as Waiting rather than failed. When you save a Multibook setting, rows that failed only because of a setting are tried again within a minute or two, without a manual sync.

Each time ANTE reads back a journal Multibook posted for one of its own documents (an invoice, a credit note, a collection or a payment), it checks that Multibook used the same account as ANTE for each GL role. If it did not (for example Output VAT 2110 in ANTE and 21190000 in Multibook), the journals step shows one line per role and pair: Multibook books Output VAT to account 21190000 but ANTE books it to 2110, with how many documents. Adopt Multibook account maps the role to the ANTE account that carries Multibook's code, so new documents post to the same account on both sides; it needs the GL account mapping permission, and is offered only when that account is already in your chart (otherwise create it or sync the chart from Multibook first). Documents already posted keep their account. The line goes away when the role is mapped to the other account, or after a week in which no document showed the difference, and finance is told by a Role account mismatch alert meanwhile.

The Readiness panel also warns when purchase orders are marked billed but have no vendor invoice: the payable could be paid twice or stay unbilled. Its button opens Vendor invoices, where you attach or create the invoice.

Developer alerts#

One alert kind is raised by a developer rather than by a fault: Sync paused for over a day appears when a developer paused a Multibook sync from the developer panel and left it off for more than 24 hours. It belongs to no single company, nothing in ANTE needs fixing, and it closes by itself once the sync is resumed under Developer, Multibook sync controls.

A red Developer alerts strip appears at the top of this page when the sync hit a problem it cannot fix by itself, for example Multibook calls on hold, a sync run that failed, a safety valve, sends that keep failing, documents waiting far longer than usual, or a Multibook key or sign-in that stopped working. The developers are notified when one opens, so nobody has to notice it by luck; they read these in their own Developer alerts bell (the wrench icon next to the notification bell, shown only to developer accounts), so the alerts never crowd the normal notification bell. Each alert says what happened, how serious it is (Critical, High or Medium), when it was last seen and how many times, and what to do about it; alerts that belong to no single company are marked All companies. The headline of an alert is written in your language, and an alert that names a screen to act on has a button that opens it: Open <module> opens that module's tab on this page, Open the <module> records goes to the page that lists the records that failed (for example the invoice list, where each failed send shows on its row), and the others open the Books card, GL Account Mapping, Cloud credentials or My Profile → Connections. An alert only a developer can act on shows Acknowledge (24 h) alone. A notice in the bell opens the page its reader can act on: finance people land on a finance page, settings administrators on the settings page, developers here.

An alert closes by itself when its cause goes away. An administrator can acknowledge one by hand with Acknowledge (24 h): it stays listed, quietly, for 24 hours (the button is replaced by acknowledged until ...) and nobody is notified again for it unless it gets worse or the 24 hours run out while the cause is still there. If the strip itself cannot be loaded, it says so instead of staying empty, because an empty strip would look like good news. An alert marked All companies (the background sync itself, shared by every company) can only be acknowledged by a developer account: anyone else is refused, and it is not muted for a day, so a fault that is still there pages again at the next check.

Books agree#

Below the readiness panel, the Do the books agree? card says whether ANTE and Multibook show the same figures for the last closed months. It is read-only and runs by itself each night; Check again runs it now (it refuses a second run within a few minutes). See Books agree for what each result means and how to fix a difference.

Deciding a held document#

A document Multibook holds for a person (an invoice, a collection or payment, a purchase order or an item movement that ANTE and Multibook see differently) is listed on its module's tab with the decisions that fit it:

• Keep both: you looked, and ANTE and Multibook stay as they are. It lasts only as long as the document is the version you looked at; if Multibook changes it again, it asks for a decision again. Nothing in either set of books changes, and a held document you decided no longer counts as needing attention.
• Cancel the ANTE order: only for a purchase order Multibook cancelled. ANTE cancels its own order to match, and refuses when anything was paid or received against it (undo the payment first).

Held journals offer the choice that fits their cause: Import it as a Multibook voucher or Ignore it for a journal that carries an ANTE reference matching nothing, and Keep ANTE's copy for a journal whose amounts differ. A journal held because an account is not in the chart, the lines do not balance, the period is closed or its code is already used by another ANTE record offers nothing: fix the cause named on its line and it imports by itself. The last cause appears after a Multibook tenant switch, when the new tenant reuses document numbers the previous tenant already imported; running the tenant reset retires the old codes, and a developer is alerted until the journal imports. Posted documents only reverse, so ANTE never overwrites one side with the other.

When a check cannot be made#

The readiness list, the Sync now checklist and the books-ownership notices are all worked out from ANTE's own data. When one of those reads fails, the page says Could not check: ... and names what it could not read, for example the Multibook credentials or the invoice pushes. What is shown next to it may be out of date: try again in a moment. A missing warning is never taken as a pass, and a connection that could not be read is shown as a check that failed, not as Multibook is not connected.

Moving to a different Multibook company#

Pointing the company at another Multibook company (a different mb-api address in Settings → Cloud credentials) is never a plain save: every link, list and document number ANTE holds describes the old company. ANTE asks you to confirm, switches every send to Multibook off, and pauses syncing. A banner then tells you the next step:

1. Clear the previous company. This asks for a one-time code, then forgets everything that points into the old company: each person's Multibook sign-in (people link again against the new company), the department, item, category and tax links, the choices in Settings that name the old company's codes, and the sends that were queued for it. Your clients, suppliers, items, vouchers and invoices are not touched.
2. Pull the new company. One click reads the new company's lists and chart of accounts; syncing resumes by itself once both are in.
3. Choose the new company's codes in Settings → Multibook and switch the sends back on (they stay off until you do).

Until the new company is pulled, a sync started by hand is refused with Pull the reference lists and the chart first: only the reference lists, the exchange rates and the chart may be run, and the other modules resume right after. If a second ANTE company is connected to the same Multibook company, saving the connection is refused unless a developer account confirms it on purpose, and readiness and an alert name the other company.

The same banner appears on Settings → Cloud credentials (Multibook tab) right after you confirm the switch, so the clear-out can be done where the switch was made. If ANTE cannot read whether a switch is pending, the banner says so with a Retry button instead of disappearing, because a half-switched company must not carry on syncing unnoticed.

When the Multibook connector is out of date#

ANTE and the Multibook connector (mb-api) are updated separately. If the connector is older than this version of ANTE needs, the readiness panel marks the affected steps Blocked ("The Multibook connector is older than this version of ANTE needs") and a developer alert opens. Nothing fails: documents wait and are sent by themselves as soon as the connector is updated, so there is nothing to retry.

Sending only one half on purpose#

Some steps belong together: sending invoices without sending the collections and payments that settle them leaves receivables open in Multibook; sending purchase orders without goods receipts (or the reverse) leaves stock and orders disagreeing. Readiness warns about such a half-pushed pair. If you do it on purpose, for example because collections are posted in Multibook, click This is on purpose on the warning; the choice is saved in Settings and the warning stays quiet for that pair.

Invoices you discarded#

Discarding a failed invoice send stops ANTE trying, but the invoice then exists only in ANTE and its books are not in Multibook. Such an invoice shows Not in Multibook with a Send again button (also in the dialog that lists unsent invoices), which puts it back in the queue.

Connection and health#

The Connection card sits beside Sync now (below it on narrower screens) and shows which Multibook the company is linked to: the host, the tenant, the company and whether the key has write access (without it ANTE can read but not file anything). The badge in its header is the call health: Healthy, N recent failures (Multibook has failed several calls in a row), or Paused until a time. When Multibook keeps failing, ANTE stops calling it for a while so it does not hammer the other system; work resumes by itself.

Four counters sit under it: Pending (waiting to be sent), Needs attention (failed and waiting for a person, tinted red when above zero), and Synced and Failed over the last 24 hours. Click Needs attention to jump to the module that has the stuck items.

Module details#

The Module details card has one tab per module, in the order the sync runs them: Reference lists, Chart of accounts, Business partners, Items, Employees, Purchase orders, Goods receipts, Invoices, Collections and payments, Journal entries, Reimbursements. A tab shows a number when that module has items needing attention, and the page opens on the first such tab. The open tab is kept in the address, so a reload or a shared link shows the same module. When all eleven tabs do not fit the card (a laptop screen), the row scrolls sideways and the open tab is brought into view, so the last tabs are always reachable. At the top of each tab, a badge shows the module's Auto-sync state: Watching keeps itself in step, Off was switched off in Settings → Multibook, Waiting for first sync means nobody has run the first sync yet, Not connected means no Multibook connection. Beside it, a line says what flows each way, and Open <module> goes to the module page.

Use View activity log at the top of the tab to open everything that moved for the module, regardless of run. This is how to inspect Reimbursements and live pushes, which are not grouped into runs.

The activity log#

The log opens in a side panel and lists every item that moved, newest first, with 50 per page. It keeps 180 days of history. For a run, the top shows the trigger, who started it, start and end, duration, outcome and counts. A run that changed nothing shows "Nothing moved in this run".

Use the chips to filter by action (each shows how many there are) and the direction buttons to show Sent to Multibook or Received from Multibook. Each row has the time, action, the item (click to open the account, voucher or claim), its Multibook reference, a message and who did it. Show details explains the row in words: the fields that changed, the reason something was held, the posting date, currency, lines and total of a voucher, or the attempt count and next retry.

Common Tasks#

How It Connects#