Billing cycles
The procedures that create bills for a billing cycle don’t include auto check box criteria the same way payment cycles do.
Payment cycles
For payment cycles, you can have invoices pre-checked when you visit the invoices screen.
Ask your finance officers to check whether any of the lines expected to be ticked fall under any of the following:
The creditor reference is missing.
Any invoices for the same purchase order are held or disputed.
Any invoices for the same purchase order were rejected fewer than the specified number of days ago.
There’s a variation or a once-only payment payable.
The first payment for an element is payable.
An element payable on the invoice ends before the invoice period ends.
The first payment after a rate change is payable.
Any elements payable is set to require confirmation before payment.
Additional details:
Checking
Checking means making a visual check that the invoice has been manually entered correctly. That is, the invoice number, amount, and so on are properly entered. Some sites have one user add the invoice, then the invoices are passed to another user to 'check' them. This would involve searching via the batch number from the previous worker and then ensuring the invoice has been added/entered correctly, that is the right cost.
With e-invoices this should not be needed – see options on the Pay cycle type set-up screen for auto-checking.
With scheduled payments, checking is not needed as Mosaic creates a ‘quasi-invoice’. Checking, however, has some rules associated with it to further ease the process for workers. Rather than Mosaic having unchecked invoices every time a cycle is generated, Mosaic applies some pre-checking rules to assist you in identifying any potential payments that do need to be checked against the original purchase.
The current rules are that invoices will not be pre-checked if any of the following statements are true:
The creditor reference is missing.
Any invoices for the same purchase order are held or disputed.
Any invoices for the same purchase order have been rejected less than specified number of days beforehand.
There is a variation or a once-only payment payable.
The first payment for an element is payable.
An element payable on invoice ends before invoice period ends.
The first payment after rate change is payable.
Any elements payable are set to require confirmation before payment.
There are any reversal payments payable.
Please refer to 1.6 Checking on Page 13 of the Mosaic: (To access the below guide, you'll need to log in to the Customer Success Portal.)
Payments user guide
Auto Check rules for Electronic Invoices:
Payment Cycle Tab
Auto check rule for Electronic Invoices is only used if the Invoice Received option is chosen and some or all invoices are to be received electronically. The Check functionality on invoice entry is intended primarily to confirm that a paper invoice has been entered correctly onto Mosaic. If invoices are imported, they cannot be incorrectly entered, but Check can acquire a different use. It can be used to confirm that a staff member has reviewed the requested payment visually rather than just accepting it.
The following options are available:
Always – The check box is always ticked. This means only that the invoice has been entered accurately.
If matched – If the invoice value matches (is the same as) the commitment value, it is checked. This means that it is assumed that if the invoice equals the expected value, then there is no need to do further checking.
Never – This means the authority will have to manually check each e-invoice that has been received.
Please refer to the Mosaic Finance Documentation on 14.1.1 Payment Cycle tab on Page 113: (To access the below guide, you'll need to log in to the Customer Success Portal.)
Finance configuration user guides
Should none of these criteria apply please raise a new case online and reference the title of this article for further assistance. Please include:
The payment cycle IDs of the current and previous cycles.
A redacted screenshot of the invoices screen.
Additional information on checkboxes
The decision to leave a box checked on a cycle starts with the Generate_Payment_Cycles stored procedure which runs a job every 5 minutes and doesn’t come from any front-end configuration.
One of the first tasks of the Generate_Payment_Cycles stored procedure, which generates the payment cycle, is to decide whether the cycle is a payment cycle or a billing cycle.
If it decides the cycle is a payment cycle, it calls the Generate_Invoices stored procedure; for a billing cycle, it calls the Generate_Debtor_Invoices stored procedure instead.
Line 622 of the Generate_Invoices stored procedure is key to your question. It sets a flag to Y pre-ticking the box on the front end only if a number of criteria are met.
In the last few lines of that section, there’s a time-limit criterion that ultimately decides whether the invoice’s checked_flag is set to Y or stays N.
For example, the date specifications
Any invoices for the same purchase order have been rejected less than the specified number of days beforehand.
What is happening with these lines of criteria?
If any invoice for that purchase order exists and is either still held or was rejected within the last 84 days (12 weeks), the box won’t be ticked. The system wants the worker to interact with these. Details on each case follow:
Held – The box isn’t ticked for a held invoice because it’s been delayed, and the worker may need to check something or confirm with other parties. The system wants to make sure the worker sees the held invoice to decide if it can now be progressed.
Rejected within 84 days/12 weeks (the default system property value) – The box isn’t ticked for invoices rejected within 84 days (12 weeks). When a cycle is raised, a new invoice is created for a specific purchase order ID. If it’s rejected in a cycle, the worker must have found an issue that needs correcting, but that invoice is now considered complete.
When a new cycle is raised, a new invoice ID is also created (the first invoice ID on the old cycle would have been rejected and have a “rejected on” date). The check box criteria looks through all rejected invoices for that same purchase order ID to see if at least one was rejected within 84 days (12 weeks).
If it doesn’t find any, the system assumes enough time has passed that the worker doesn’t need a continual reminder. If it does find rejected invoices within 84 days (12 weeks), the system considers the invoice still fairly recent and thinks it’s a good idea to keep reminding the worker to check if it can be progressed.
For non-hosted customers, you can query your database to find the specified number of days as follows:
Select * from System_Properties where Name like '%InvoicePreCheckAfterDaysRule%'
From Mosaic version 22.1 onwards, users can amend this system property via the front end, and all changes are audited.
If you run cycles every two weeks and reject the same purchase orders each time, the system will keep the boxes unticked for the reasons above.