Problems
Document date cannot be before the lock date
Xero refused the document because it is dated on or before a lock date, and moving that lock in Xero is the fix both practice systems give. Read which leg was named. A refused invoice leaves nothing in Xero at all. A refused payment leaves the invoice sitting open and the funder clearing balance short of a deposit already on its way.
Key facts
- The exact wording Cliniko reports
- Two separate errors with two separate fixes: the document date cannot be before the period lock date, and the document date cannot be before the end of year lock date4
- The exact wording Zanda reports
- That an invoice date or its payment date are within the locked period when changes to the transactions are not allowed2
- Why two legs can behave differently
- Zanda exports in two batches, invoices first and then payments, and filters payments by the day the payment was applied rather than by the invoice date3
- When each leg is sent
- Cliniko pushes an invoice as soon as it is created and a payment only once it is allocated, so an unallocated payment has not reached Xero yet1
- What Cliniko tells you to do
- The same first step for both errors: adjust the lock date in Xero, then resync invoices from Cliniko4
- What Zanda tells you to do
- Remove or update the lock dates in Xero, then disconnect and reconnect the integration before exporting invoices and payments again2
- How fast the backlog drains
- Cliniko states Xero's API allows one payment to be sent each minute, so a held batch of receipts arrives slowly after the lock moves1
What the message actually says
The wording is worth reading closely, because the practice system reports more than one version of it and the versions are not interchangeable. Cliniko lists them as separate failures with separate fixes. Zanda reports a single message with a wider scope.
| System | The message | What it names |
|---|---|---|
| Cliniko | The document date cannot be before the period lock date. | The period lock, and not which leg was refused. Cliniko lists it as its own failure with its own fix. |
| Cliniko | The document date cannot be before the end of year lock date. | The year end lock, a separate line in Cliniko's list carrying the same fix. |
| Zanda | An invoice date or its payment date are within the locked period when changes to the transactions are not allowed. | Either leg, without saying which of the two locks was hit. |
So the message you have already narrows things. Cliniko's tells you which lock and not which leg. Zanda's tells you it could be either leg and not which lock. Neither tells you both, which is why the next two questions have to be answered by looking rather than by reading.
Which leg was refused
An invoice and the payment against it are two separate writes into Xero, carrying two separate dates, sent at two different moments. The lock is applied to each of them on its own. That is the part the error message hides, and it is the part that decides what you are looking at in Xero.
- The invoice leg was refused: nothing about that appointment exists in Xero. The revenue is missing, the debtor is missing, and the practice system is the only place the charge lives.
- The payment leg was refused: the invoice is in Xero and sitting open. The revenue is right, the debtor is overstated, and the funder clearing account is short by the amount of the claim.
- Both were refused: the whole appointment is missing, which is the usual shape when a lock is set across a month that was never exported.
Zanda makes the split easy to see, because its export is run as two batches, invoices first and then payments, and it filters payments by the day the payment was applied rather than by the invoice date. An appointment invoiced in an open month and paid by a funder inside a closed one is exactly the case where the first batch lands and the second is refused.
Why a connected system is refused at all
The refusal comes from the Xero file rather than from the connection. A lock date closes a Xero organisation to transactions dated on or before it, and both vendors point the fix at the same place, which is the lock date in Xero. Neither offers a setting inside the practice system that clears it. Zanda's extra steps, a disconnect and a reconnect, come after the lock has been moved.
There are two of these lines rather than one, and the API names them PeriodLockDate and EndOfYearLockDate on the organisation. Xero's own pages could not be read for this page, so those names come from this repository's API notes and not from Xero, and that gap is stated in the open questions below. Which users each of the two locks stops, and whether a connected app is stopped by both or only by the harder one, is not settled by either vendor's help centre. Xero lock dates and a practice software export that will not land runs the procedure for clearing one and reads the two locks against the roles that can move them.
Why an allied health practice meets this on the payment leg
In a practice that bills patients on the day, the invoice and its payment carry the same date and the two legs stand or fall together. Funder money does not behave that way. The service happens in one month and the funder pays in another, and the payment is dated on the day the funder actually paid rather than on the day the money was banked.
That is the whole point of dating it that way. It is what makes the debtor ledger close on the day the claim was approved and what makes each funder clearing balance a list of claims approved but not yet banked. It also means a payment report reconciled a week into the next month writes a payment back into the month just closed, which is the month somebody has usually just locked.
What a blocked payment leg leaves behind
A refused payment is quieter than a refused invoice, which is why it is the worse of the two. The revenue is already in Xero on the right date, the reports for the month look finished, and nothing on the profit and loss moves. What moves is further down.
Three places it shows up in Xero
Because a blocked payment leg does not raise anything in Xero itself, it shows up as three symptoms that are usually chased separately by three different people.
- Aged receivables carries invoices the practice system shows as paid, so the debtor report and the practice system stop agreeing.
- The funder clearing account holds less than the deposit that is coming, so the bank line cannot be matched against a balance that is not there.
- The practice system's own reports look right, because the money was received there. Only Xero is missing it, which is why the fault is often found from the bank side rather than from the failed export list.
Chasing any one of those alone leads to a workaround. Keying the payment into Xero by hand fixes the debtor and leaves the practice system and Xero holding two different payment records for the same claim, which is the thing that comes back at the next reconciliation.
The choice the message hides
Both vendors give the same first step: change or remove the lock date in Xero and export again, with Zanda adding a disconnect and a reconnect in between. It is a reasonable answer and it is not the only one. Once a document has been refused there are three ways forward, and they put the transaction in different months.
- Move the lock, let the document in on its own date, and put the lock back. The clearing balance is restored on the day the funder paid, and every report of that month changes by the amount of the document.
- Leave the lock alone and re-date the document to the first open day, with a note naming the day it belongs to. The closed month keeps the figures already reported, and the clearing balance appears in the month after the one the claim was approved in.
- Hold the document out of Xero and put it to the accountant as a question. Nothing moves, the clearing account stays short, and the bank line waits with it.
Which one belongs to a given practice turns on whether the period's activity statement has been lodged, and on a cash basis it is the payment date that decides which quarter the receipt falls in. That call belongs to whoever signs the statement. Cash and accrual BAS in Xero sets out the split.
After the lock moves
There is a second surprise waiting on the other side of the unlock. Cliniko states that Xero's API allows one payment to be sent each minute, and that older payments can take a few hours or even days to appear, so a held batch of receipts does not arrive at once. Invoices go across as they are created and payments only once they are allocated, so a released backlog usually lands as all of the invoices and then a slow drip of receipts behind them.
That matters here because the invoices are the leg that was probably never blocked. Watching them arrive says nothing about whether the receipts followed. Read the funder clearing balance instead, and treat the job as finished when the balance matches the deposit that is coming rather than when the failed export list empties.
What Ledger Map does with it
Ledger Map holds one standing map for the practice, approved before anything syncs. A document dated inside a locked period is not re-dated quietly and is not dropped. It is queued and raised as a question carrying the same three options: let it in on its own date once the lock moves, re-date it to the first open day with a note naming the day it belongs to, or hold it until the accountant answers.
Nothing posts until the practice picks one. When it does, the deposit goes in as one balanced document set and one exact match is left in the bank feed for a person to accept. How it works shows the map and the approval step, and the two practice systems this page draws on are covered on Cliniko and Zanda.
Questions
What does the document date cannot be before the period lock date mean?
It means Xero refused a transaction because it is dated on or before a lock date the organisation has set. The refusal comes from the Xero file rather than from the integration, which is why the fix sits in Xero and not in the practice system. Cliniko reports this as one of two separate errors, the other naming the end of year lock date, and gives the same fix for both: adjust the lock date in Xero, then resync invoices.
Was it the invoice or the payment that Xero refused?
Either one, and the message does not say. Zanda's version of the error names an invoice date or its payment date, which is the clearest statement that both legs are checked separately. Look in Xero: if the invoice is there and sitting open, the payment leg was the one refused. If nothing about the appointment is there at all, the invoice leg was refused too.
Why does the funder clearing account still look short after I fixed the invoice?
Because the invoice and its payment are two writes, and only the payment moves the clearing balance. If the invoice landed and the payment was refused, the revenue and the debtor are in Xero and the claim is not sitting in the clearing account, so the bank deposit arrives with no balance to clear against. Check the clearing balance rather than the invoice list.
Can I just key the payment into Xero by hand?
Keying the payment in by hand closes the invoice, and it leaves the practice system and Xero holding two records of the same receipt, so the next export can try to send the payment again once the lock moves. If a payment is entered by hand, note it in the practice system as already in Xero and read the invoice afterwards to be sure only one payment is allocated against it.
Which month should the blocked payment end up in?
That depends on what has already been reported for the closed month. Letting the payment in on its own date puts the receipt in the month the funder paid and changes the figures for a month that has been reported. Re-dating it to the first open day leaves those figures alone and moves the receipt into the next month instead. On a cash basis the payment date is the one that decides which quarter it falls in, so the call belongs to whoever signs the activity statement.
Read next
- Xero how toXero lock dates and a practice software export that will not land
- Xero how toCash vs accrual GST for a clinic in Xero
- Practice systemsCliniko Xero integration: what syncs, what does not
- Practice systemsZanda Xero integration: what the batch export carries
- ProblemsInvoices paid by account credit stay open in Xero
- ProblemsArchived Cliniko invoice is still open in Xero
- HubProblems
Sources
Open questions
- Xero's own documentation could not be read for this page. Xero Central's lock date article, the developer Organisation page and the developer types page each returned an empty document, so the two API field names rest on this repository's own API notes and no key fact cites Xero.
- Whether Cliniko's period lock date and end of year lock date are Xero's own screen labels or the practice system's paraphrase of the two API fields is unconfirmed.
- Which users each of the two locks stops, and whether a connected app is refused by both of them or only by the harder one, is not answered by either vendor's help centre. The how-to page reads the two locks against the roles that can move them.
- Whether to re-date a blocked document or hold it is a question for the practice and whoever signs its activity statement. This page sets out what each choice does and does not settle it.
- No first-party figure exists for how often a lock date blocks an allied health sync. The corpus records four vendor sources for this pain point and no volume data, so the page states the mechanism and no frequency.
- No practitioner quote about a lock date exists in the corpus. The complaints for this pain point sit in vendor troubleshooting pages rather than in public forums, so the page carries no quote rather than a borrowed one.
Review
Last reviewed 3 Sep 2026 by Shane
General information for Australian allied health practices, not tax advice. Confirm a treatment with your BAS agent or accountant before you post it.
Guided onboarding
Run one real month before you go live.
Sign up, connect Zanda and Xero, and replay a month you already closed. The map is reviewed with whoever owns the books, and nothing posts until you approve it.
Every practice starts from a template. Nothing posts until the map is approved.