What we shipped, in plain language.

Accounting spans receivables, payables, the general ledger, banking, assets and reporting, and finding a screen meant knowing which branch of the menu it lived under. The new landing page lays the whole module out as grouped tiles, so the destination is visible rather than remembered.

The dashboard reported only the payable side, and the unallocated-payments figure was never rendered at all. It now carries the full advance position.

• Six new indicators: Advances Outstanding, Advances Paid Year to Date, Advances Pending, Advances Over 180 Days, Unallocated Payments and Net Exposure
• Ageing buckets for open advances, a six-month paid versus adjusted trend, and top vendors by open advance
• A drilldown that lists the open advances behind any bucket, one row per down payment request

Descriptions, notes, terms and correspondence leave your company and are read by customers and suppliers. The Writing Assistant checks them as they are typed and suggests corrections in place.

• Runs on a service hosted alongside the application — your text is not sent to any third party
• Enabled per tenant from its own settings screen, with the fields it applies to under your control
• Ships inert: until it is switched on, every field behaves exactly as it does today, and if the service is ever unreachable the form still saves normally

Layout, filtering and data-entry improvements on the Customer Payments page, following the ledger statement corrections in the same release train.

Analytics components that were no longer part of the product — and a scheduled refresh job that had never succeeded — have been removed, along with roughly 4 GB of unused machine-learning runtime. Faster deployments, less to go wrong, and nothing you use is affected.

Firewall rules were reconciled against the services actually listening, database access was restricted to the application tier, and repeated authentication failures are now blocked automatically.

The Vendor Ledger statement disagreed with itself in several places at once.

• The running balance accumulated newest to oldest, so the statement printed backwards — the newest row showed its own movement alone and the oldest showed the closing balance
• The statement keyed on the document date rather than the posting date. A sub-ledger that does not run on the General Ledger date cannot be reconciled to the General Ledger
• An opening balance brought forward into the selected window is now shown, so a filtered statement still ties

Customer Ledger and General Ledger carried the same statement defects and have been corrected on the same terms — posting-date ordering, a forward-running balance, and a balance brought forward.

Any statement line now opens the underlying accounting document with its full set of journal lines, so a query on a balance can be answered without leaving the ledger.

One document type can carry several series — by company, branch, or any variant you distinguish — so each stream of documents keeps its own running number.

A variant that could never fire is refused at configuration time rather than discovered later as a gap in the sequence.

Every document type — orders, invoices, receipts, notes, vouchers — can now be given its own numbering rule: prefix and suffix, sequence width, and how and when the counter resets.

• Maintained as data, per company and per document type
• A document type you have not configured numbers exactly as it did before — adopting the feature is a decision you make one type at a time
• Numbers already issued are never renumbered

Before a change is released you can see what it touches: which orders are already open against the affected lines, and a decision recorded per order about what should happen to it.

• Change register with search and filters, plus a detail view of everything a change proposes
• Change history on the BOM itself — what changed, when it took effect, and under which change order

Once a BOM is released, production orders, purchase orders and budgets have been planned against it. Editing it in place changes what those documents were costed on, silently. A released structure is now changed only through an Engineering Change Order.

• Draft, submit, approve, reject or cancel a change, and raise a counter change that stages the exact inverse
• Release either by line effectivity (end-date the old line, start the new one) or as a new version of the structure
• Every change carries a category and an effective-from date, so which BOM applies on a given day is a single, unambiguous answer
• If somebody moved a field underneath the change while it was in flight, the release is refused and the field named — it is never silently merged
• There is deliberately no un-release: a release has a date, and work has been planned against it

The BOM endpoints previously required only a signed-in user, so any user of the tenant could create, edit or delete any BOM at any plant. They now require explicit BOM permissions, and two focused roles ship with the feature: BOM Engineer (authors and raises changes) and Engineering Change Approver (approves, releases and decides impact).

Administrators: review role assignments as part of this upgrade so the BOM screens stay available to the people who need them.

A post dated cheque is a promise for a future date, not a receipt today. Post Dated Cheque Management records the instrument when it is taken, holds it until its due date, and carries it through presentation, clearing, dishonour and return — with the accounting following the cheque rather than the calendar.

• Register cheques received and cheques issued, with their instrument dates and banks
• Track each cheque through its lifecycle to clearance or dishonour
• See what is maturing, and what remains on hand

Usability and presentation improvements across the Customer Payment screen so a receipt can be captured and checked against the customer’s open items in fewer steps.