API release notes 3.0.1

• New Endpoints

• Updated Endpoints & Enhancements

  • Enhancements to Accounts Receivable Endpoints

  • New Clients Endpoints

  • New Contacts Endpoints

• Developer Notes

New Endpoints

New Endpoint: /accountsreceivablebatches/batchprocess

We’ve introduced a new endpoint designed to streamline batch processing, reduce manual overhead, and minimise potential points of failure. The /accountsreceivablebatches/batchprocess endpoint allows batch details, receipts, and allocations to be submitted in a single request, simplifying the workflow while maintaining secure and controlled processing.

Streamlined, Single-Step Workflow

• Automatically creates the batch

• Inserts receipts into the system

• Applies allocations for each receipt

• All actions are performed in one API call — eliminating the need for multiple steps or endpoints

Secure and Controlled Processing

The batch is:

• Flagged as sealed: Preventing users adding to the batch in the UI.

• Flagged as locked by the user: Preventing other users performing approvals in the UI until processing is complete.

Validation Logic

• The endpoint bypasses certain standard workflow triggers and validations that are not relevant in this controlled integration context

• This is based on the assumption that:

  • The data is sourced from a trusted system

  • The batch is not intended for user interaction until processing is complete

• All core system validations still apply, ensuring data integrity remains intact.

• Core validations are applied upfront for the batch and all receipts prior to posting minimising chances of issues during processing.

• Warnings may be raised during posting but do not prevent posting itself (e.g. if a user in the UI has manually allocated against an allocation target for a post and there is no longer sufficient balance to apply the specified allocation).

Response

The response returns the following: -

• BatchID – The ID of the finished batch or 0 if no batch was created.

• Approved – Boolean flag that indicates if the batch was successfully approved. NOTE – Approval can be prevented by external factors such as another user initiating a Period Lock for period close or mixed factors such as where full allocation of an item is required for approval and amounts were either not fully allocated by the request or could not be fully allocated due to balances on targets not being sufficient to make the allocations that were requested.

• Messages - A collection of errors and/or warnings. A message consists of:-

• RowIndex – The index (1 based) of the receipt in the original request. Contains -1 if the message does not pertain to a single row.

• TargetNomID – ID of the nominal A nominal account is a general ledger account that you close at the end of each accounting year. record that is the target of the error/warning.

• Error – A boolean flag that indicates if the message is an error or warning.

• Message - A verbal indication of the issue for displaying to the user.

This new endpoint provides a faster, safer, and more efficient method for handling batch-based financial transactions — particularly in trusted, automated integration scenarios.

New Alert Endpoints

As part of our expanding Alert API suite, we’re introducing several new endpoints designed to help clients proactively monitor key operational data and trigger timely actions.

Note: All endpoints are GET-only and do not modify data.

/alerts/DraftBillsAwaitingApproval

Returns draft bills that are awaiting approval, filtered by query parameters minDaysPrepared (mandatory) and approvalStage (optional). Ideal for triggering reminders and ensuring timely billing workflows.

/alerts/monthyearend

Provides read-only access to VW_ClientMonthYearEnd, allowing clients to identify entities with upcoming financial year ends. Useful for triggering planning and compliance-related alerts.

/alerts/missingtime

Returns a list of staff members with missing time entries for Non-TSC only, helping teams ensure complete and accurate timesheet data ahead of billing or payroll deadlines. NULL Units are handled by adding ISNULL around the units' field.

/alerts/invoicesunpaid

A read-only endpoint that returns a list of invoices unpaid filtered by a mandatory query parameter minDaysUnpaid, supporting automated credit control workflows and visibility over aged receivables.

These endpoints are part of our effort to help clients automate reminders, enforce operational standards, and reduce manual monitoring through targeted, real-time alerts.

---

Updated Endpoints & Enhancements

Enhancements to Accounts Receivable Endpoints

We’re pleased to announce several enhancements across key accounts receivable endpoints to support more detailed reporting, improved currency visibility, and additional metadata for downstream integrations.

/client/{ClientID}/AR

• New Fields:

  • BillStageType – Indicates the current stage of the bill.

  • PrintedDate – Date the bill was printed.

• Currency Reporting Improvements:

  • Enhanced visibility into transaction currency details, supporting more accurate financial reporting and reconciliation.

• Job-Level Metadata:

  • Invoice line items now include additional job-level information: Partner, Manager, Supervisor, JobID and JobName

  • As well as: Nomid, parentNomid, amount, tax_Amount, notes and description

  • Supports:

    Credit card processing logic tied to job details.

    Filtering and reporting on client dashboards using job-specific data.

/accountsreceivable/search

This endpoint now mirrors the enhancements made to /client/{ClientID}/AR for consistent data structures and reporting capabilities across both endpoints.

/accountsreceivablebatches/banks/{BatchType}/{BatchSubType}/{Entity}

Now includes:

• AccountShortCode – In addition to the existing AccountDescription, this provides a concise, system-recognisable identifier for the bank account.

/clients/modified/{timeStamp}/{offset}/{limit}

Returns Clients with a timestamp after the provided timestamp.

Now includes:

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

/contacts/modified/{timeStamp}/{offset}/{limit}

Returns Contacts with a timestamp after the provided timestamp.

Now includes:

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

New Clients Endpoints

Note: Below endpoints return the records from tblAuditTrail table.

/clients/modifiedsincedate/{timeStamp}/{offset}/{limit}

Returns Clients with a timestamp after the provided timestamp. The offset and maximum number of records can be provided.

• TimeStamp – Is a mandatory datetime parameter. e.g. 2025-06-05:00:00:00

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

/clients/modifiedsincedays/{days}/{offset}/{limit}

Returns Clients modified in the last x days. The offset and maximum number of records can be provided.

• days– Is an integer parameter.

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

New Contacts Endpoints

Note: Below endpoints return the records from tblAuditTrail table.

/contacts/modifiedsincedate/{timeStamp}/{offset}/{limit}

Returns Contacts with a timestamp after the provided timestamp. The offset and maximum number of records can be provided.

• TimeStamp – Is a mandatory datetime parameter. e.g. 2025-06-05:00:00:00

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

/contacts/modifiedsincedays/{days}/{offset}/{limit}

Returns Contacts modified in the last x days. The offset and maximum number of records can be provided.

• days– Is an integer parameter.

• Offset - Is an optional parameter with default value 0(zero)

• limit - Is an optional parameter with default value 50

Developer Notes

• Refer to the updated API documentation for the full schema.

• Sample response payloads have been updated to include new or enhanced fields.

• Ensure downstream systems are configured to handle and store any new fields if needed for reporting.

Backward Compatibility Maintained

Existing integrations will continue to function as expected. New fields are non-breaking and optional to consume.