Red Release Notes 21/10/2026

This release improves Red’s sales entry and cash receipt workflows, with better support for signed sales entries, multiple VAT lines, larger sales-entry batches and safer cash receipt reallocations. It also includes improvements to routing, filtering, balance handling and write-confirmation guidance.

Sales Entries

Zero and negative sales entries

UPDATED: Red now supports sales entries with zero or negative values.

Previously, sales entry validation could reject amounts that were not greater than zero.

Red now:

• accepts zero-value sales entries;
• accepts negative sales entry values;
• preserves the requested sales-entry record type rather than changing the transaction type because an amount is negative;
• applies the same preview and confirmation requirements before anything is written.

This provides more flexibility when working with adjustments and other signed sales-entry values.

Multiple VAT lines on sales entries

NEW: Sales entries can now contain multiple VAT lines.

Previously, Red supported a single VAT value when creating a sales entry.

Red now supports a vatLines collection so a sales entry can contain more than one VAT treatment where required.

The existing single-VAT format remains supported for compatibility.

This allows Red to represent sales entries containing different VAT rates more accurately before they are submitted to Big Red Cloud.

Larger sales-entry batches

UPDATED: Red can now process sales-entry batches of up to 100 entries per request.

Previously, the default batch size was limited to 20 entries.

Red now:

• supports up to 100 sales entries in one request;
• uses the configured sales-entry batch limit when no explicit batch size is supplied;
• rejects requests above the 100-entry limit before anything is submitted;
• does not silently split an oversized request into several separate writes.

The 100-entry ceiling is retained to keep requests within Red’s current transport limits.

Each batch still requires a preview and explicit confirmation before it can be written.

Cash Receipts

Safer customer reassignment

UPDATED: Red now performs stronger validation when moving an existing cash receipt to another customer.

When a cash receipt update changes its customer, Red now requires both the Big Red Cloud customer ID and account code.

The pair is checked against the selected company before the update can continue.

This prevents a receipt from being reassigned using a customer ID and account code that belong to different customer records.

Improved cash receipt reallocations

UPDATED: Multiple cash receipt reallocations can now be previewed more efficiently as part of the same approved request.

When one request clearly identifies several cash receipts to be updated, Red can reuse the same routing authorisation across those previews instead of unnecessarily routing each receipt separately.

Each individual receipt still receives its own preview, and nothing is written until the user explicitly confirms the changes.

Improved receipt and customer filtering

UPDATED: Red can now apply additional filtering when retrieving cash receipts and customers.

Improvements include support for:

• filtering cash receipts by processing date;
• filtering cash receipts by customer;
• exact customer account-code matching;
• bounded local filtering when the Big Red Cloud endpoint does not provide the required filter directly.

This makes it easier to find the correct records without returning unnecessarily large result sets.

Clearer cash receipt update confirmation

FIXED: Red no longer incorrectly asks for an additional counterparty confirmation flag when updating an existing cash receipt.

Cash receipt updates use the normal Red write process:

1. Red shows the proposed update as a preview.
2. The user explicitly confirms the change.
3. Red submits the update with write confirmation.

If the customer itself is being changed, Red still validates the customer ID and account code before allowing the update.

The additional confirmCounterpartyExplicit parameter continues to apply to workflows that genuinely require it, such as creating relevant customer-linked records.

Routing

Improved sales entry routing

FIXED: Red now recognises more natural ways of asking to create or preview sales entries.

Requests referring to manual invoices, sales-entry batches or previews are now less likely to be left unclassified or sent to an unrelated workflow.

For example:

“Import the October manual invoices into Big Red Cloud as sales entries.”

will correctly remain in the sales-entry workflow.

Improved cash receipt reallocation routing

FIXED: Requests to reallocate, reassign or move an identified cash receipt are now routed more reliably to the cash receipt update workflow.

For example:

“Preview reallocating these cash receipts to UTSMOKE.”

will now be treated as an update to the existing receipts rather than an unrelated read or create request.

Improved handling of follow-up reporting text

FIXED: Reporting phrases at the end of an action request no longer override an otherwise clear accounting action.

For example, a request such as:

“Preview reallocating these cash receipts and tell me how many were included.”

will remain in the cash receipt update workflow.

Previously, phrases such as “tell me how many” could cause the request to be interpreted as a help or read-only question instead.

Balances and verification

Improved balance handling

UPDATED: Red now distinguishes more carefully between an explicit zero balance and a balance that Big Red Cloud did not return.

If Big Red Cloud explicitly returns a balance of 0, Red preserves that value.

If a balance field is missing, null or invalid, Red treats it as unavailable rather than automatically converting it to zero.

Red also records where the balance was obtained and whether it was independently verified against another Big Red Cloud response where applicable.

This reduces the risk of presenting missing balance data as though it were a confirmed zero.