Notifications Center

Unified notifications panel for: Approvals Expiring registrations Insurance documents Budget variations Compliance alerts Workflow reminders (checklists, terminations, settlements) Supports email, SMS, and in-app notifications (e.g.: fuel overspend, holiday office hours, service overdue) Fully auditable Apply Regular Expression (regex) validations to fields

Ability to Edit Generated Email Before Sending

Before sending any system-generated email (quote acceptance, rollover, termination notices, approvals, reminders): Users must be able to: Edit subject, body, and attachments View merged field outputs See which fields must not be removed (e.g., signed URLs, OTP tokens) Save the final sent version to the audit history Make per-send customisations without changing master templates

Termination Automation

Goal: Automate renewal outreach and end-of-term actions. Identify contracts approaching termination (30/60/90-day windows) Applies Event Templates Trigger workflows based on time/status change Bulk termination/rollover management Template-driven email/SMS sequences (mail merge) Auto-generate extension offers Task orchestration for inspections, buyouts, and final invoices Funnel analytics: contacted → responded → rolled over Full audit history

Automate periodic lease credit note creation

Right now someone has to create credit notes for periodic leases by hand every time. That's slow, easy to get wrong, and it means the Lease and Payment records can drift out of sync. We want to automate it, without touching the bits that are deliberately manual. What's in Periodic lease credit notes, both full month and partial month, posted automatically to the Lease tab and the Payment tab (principal, interest, finance). What's out Recharge (approval) credit notes and COVID-19 relief credits. Those stay manual, no change. How it works There's a new Credit button on the Lease tab. The user enters the Contract ID, picks the period they want credited, hits Credit, and the system asks whether it's a full or partial month (F or P). Full month: we just reverse the lot. Opposite-sign entries for the lease rental amounts on the Lease tab, and for principal, interest and finance on the Payment tab. Partial month: we show the rental start and end dates for that period, then ask for a Credit From date. It has to sit inside the rental period. From there we work out how many days are in the rental month, how many days we're crediting (credit date through to rental end date, inclusive), then pro-rate it: monthly amount divided by days in month gives the daily rate, times credit days gives the credit. Same as above, opposite-sign entries go to both tabs, with principal plus interest still equalling finance. Validation and safety nets Standard Catch-e prompts, so "OK to Save?" and "Cancel". Every credit needs to stay auditable and traceable back to the original lease period, and the maths has to line up with the existing lease schedule data. Reporting and accounting Credits show up correctly in lease schedules, sync properly with payment records, and finance integrity holds (principal + interest = finance). Done when A user can raise a full or partial periodic lease credit in one guided flow, both tabs update automatically and stay consistent, recharge and COVID credits behave exactly as they do today, and nobody has to touch a standard periodic lease credit note by hand again.

Default Disclose to true on all lines

In a Sales batch, only the first line gets Disclose = True automatically. Every other line starts unticked, and the Sales Invoice only prints lines where Disclose is ticked. So users have to remember to tick each remaining line by hand. It's fiddly, and worse, it's easy to miss a line, which means it silently drops off the invoice. Objective Flip the default. All Sales lines start with Disclose = True, and users untick the ones they don't want on the invoice. Same outcome, far less manual work, and the failure mode changes from "line quietly missing" to "line the user chose to remove". In scope Default Disclose = True on all lines in a Sales batch, not just the first Users can still untick any line Applies to lines added after the batch is created, not just the initial set Out of scope Any change to how the Sales Invoice document decides what to print (it still prints ticked lines only) Other batch types or other uses of the Disclose field Functional requirements Default on create. When a Sales line is created, Disclose is set to True. This covers lines created as part of the initial batch and any line added later. Manual override. Unticking works exactly as it does now. Once a user unticks a line, that stays unticked, nothing re-ticks it on save or refresh. Existing batches. Open, unposted batches created before the change keep their current tick state. We don't retrospectively tick anything. Worth confirming this is what's wanted. Validation and audit Standard Catch-e prompts on save Disclose changes should be traceable in the audit trail the same way they are today, so we can tell "user unticked this" apart from "system never ticked it" Acceptance criteria Creating a Sales batch results in every line having Disclose = True Adding a line to an existing batch gives it Disclose = True Unticking a line stops it printing on the Sales Invoice, and it stays unticked The Sales Invoice prints all ticked lines and nothing else No change to any other batch type

Date First Held field remains locked for PHEVs in Quoting Stage

When quoting a PHEV, the Date First Held field stays greyed out and can't be edited. This holds even after the quote is set up to meet the conditions that should make the field relevant — Used/Demonstrator, EV Exempt Reportable ticked, LCT set to 0.00. The practical impact is on existing client vehicles. Budget adjustments on a vehicle already held need the actual date first held, and there's currently no way to enter it at the quoting stage. Users are stuck. Why the field matters here For PHEVs, date first held isn't cosmetic. The PHEV FBT exemption ended for new arrangements from 1 April 2025, with transitional treatment depending on when the vehicle was first held and whether a binding commitment existed before that date. So the date drives whether the exemption applies at all. Anything we do here needs to keep that logic correct, not just make the field typeable. Objective Allow Date First Held to be entered at the quoting stage for PHEVs where the vehicle is already held, without weakening the FBT logic that depends on it.” In scope Unlocking Date First Held in quoting for PHEV vehicles that meet the relevant conditions Feeding the entered date into FBT exemption determination and budget calculations Whatever validation is needed to stop the field being misused Out of scope Changing FBT exemption rules themselves Behaviour for BEVs or ICE vehicles, unless the fix turns out to be shared logic Post-quote stages where the field is already editable Functional requirements Find out why it's locked. First step is establishing what currently drives the lock: fuel type, new vs used, quote stage, EV exemption flag, or a combination. The user has already tried the obvious levers without success, which suggests the condition is either stricter than expected or the field is simply disabled at quote stage regardless. That answer shapes the fix. Unlock condition. Once known, define the specific condition under which the field becomes editable. The likely shape: PHEV, Used/Demonstrator, and an existing vehicle rather than a new acquisition. Needs to be tight enough that it can't be used to backdate a new PHEV into an exemption it isn't entitled to. Validation. Date entered can't be in the future. It should sit sensibly against the vehicle's build or compliance date and the contract start. Where the date implies FBT-exempt treatment, the system should apply the relevant checks rather than taking the date on trust. Downstream effect. The entered date flows through to FBT exemption determination, the budget calculation, and anything on the quote that displays exemption status. Changing the date recalculates the quote.

Increase Scheduler Job Recipient Limit Beyond 10 Recipients

Currently, scheduler jobs are limited to a maximum of 10 email recipients. Some customers need to distribute scheduled reports, notifications, and automated outputs to larger stakeholder groups, and the existing hardcoded limit requires manual workarounds or multiple scheduler jobs. Requested Enhancement Increase the recipient limit for scheduler jobs beyond the current maximum of 10 recipients, or make the limit configurable at a system level. What's happening now When configuring recipients for a scheduler job, the email distribution list is capped at 10 addresses. This is a hardcoded limit, so it's currently not possible to notify more than 10 people from a single scheduled job. The ask The ability to add more than 10 email recipients to a scheduler job's distribution list, ideally with a higher or configurable limit. This would let scheduled reports and notifications reach everyone who needs them, without having to split recipients across multiple jobs.

Event Description field: Allow line breaks

A customer has raised that the Description field on Events won't accept a line break. When they press Enter to start a new line, the cursor jumps to the next field instead. Shift, Ctrl and Alt + Enter all do the same thing, so there's currently no way to break the text up. Any note longer than a sentence ends up as one unbroken line that's hard to read back later. The workaround they've been given is to separate points with a dash or semicolon, but that's still one block of text and doesn't help when they want a note laid out over a few short lines. Request The ask is for the Description field to accept line breaks so notes can be written across multiple lines. Pressing Enter should start a new line within the field, and those line breaks should be saved and shown the same way when the note is reopened. In scope The Description field when adding or editing a note on an Event. Out of scope Other description or notes fields elsewhere in the system, and rich text formatting such as bold, bullets or headings. This is plain multi-line text only. Functional requirements Pressing Enter in the Description field should start a new line rather than move to the next field. Tab should still move to the next field so keyboard navigation isn't lost. Any line breaks the user enters should be saved and shown back the same way when the note is reopened or edited, and wherever else the note appears. Validation and audit No change to who can add or edit an Event note. Anyone who can do it today can still do it, with no new permission needed. Existing single-line notes stay exactly as they are, with nothing reformatted or lost. Why it matters to the client Notes on Events are often more than one sentence. Being able to break them into separate lines would make them much easier for the client to read and quicker to scan later.

Client-level PAYG tax scale override

Right now the PAYG withholding scale (Scale 1 through Scale 7) is one setting in Global Controls, and it applies to every client's quotes at once. There's no way to give one client a different scale from everyone else. A client needs all their employees quoted using the "no tax-free threshold" scale, because none of their staff claim the threshold. Because the setting is global, we can't do this without changing quotes for every other client too. Objective A client can be set up so their quotes use a specific PAYG scale, different from the system default, without affecting any other client. If nothing is set for a client, quoting behaves exactly as it does today. In scope / Out of scope In scope: a client-level setting for PAYG scale, and quote generation checking that setting before falling back to the global default. Out of scope: changing how the global default itself works, building an interface for bulk-editing scales across many clients at once, and anything to do with payroll or repayment calculations that happen after a quote is accepted. That last one is a genuine unknown, not a decision, and it's called out below. Functional requirements Where the setting lives. Add a PAYG scale field at the client level, sitting alongside the client's other configuration. It should be optional. A blank value means "use the system default," which is the current behaviour for every existing client, so nobody needs to be migrated or touched. What quoting does with it. When a quote is generated, the quoting logic checks the client's own PAYG scale setting first. If one is set, use it. If not, fall back to the global Scale setting, same as today. This needs to sit in the one place quotes actually read the scale from, not be duplicated logic bolted on beside it, or the two will drift out of sync over time. The assumption worth naming. The request assumes the PAYG scale only matters for quote generation. We don't actually know that yet. If the same Global Controls value is also read anywhere downstream, such as actual payroll deductions, repayment schedules, or anything exported to an employer's payroll system, then this isn't a contained quoting change any more, it's a change to numbers that affect real pay. That needs to be confirmed with engineering before this is scoped as "quote-only," and if it turns out the scale is used more widely, this brief and its cost estimate need to be revisited, not quietly extended to cover it. Who decides the client should be on Scale 1. Whether a given client's workforce genuinely doesn't claim the tax-free threshold, and there

Receipts Allocate Visibility & Historical Receipt Allocation Improvements

On the Receipts Allocate screen, users can't always allocate a historical receipt to the invoice it belongs against. Sometimes no outstanding invoices show up at all; other times the screen's filters are hiding invoices that are actually there. Either way the user is stuck. The workaround people fall back on is re-keying the receipt, which creates a duplicate and makes a mess of the ledger. So the current gap isn't just an inconvenience, it's actively pushing users towards a bad outcome. Objective Let users find and allocate a historical receipt against the correct invoice from the Receipts Allocate screen, without creating a duplicate receipt and without posting incorrectly to the ledger. In scope Allocating receipts dated in prior periods to invoices on the Receipts Allocate screen Fixing or relaxing the filters so genuinely allocatable invoices are visible Making it clear on screen when nothing is returned and why Preventing duplicate receipts arising from the workaround Out of scope Changing how receipts are created or imported Reopening closed accounting periods Any change to allocation logic itself once the correct invoice is selected Functional requirements Diagnose the two failure modes separately. These look the same to the user but need different fixes: Filter problem: the invoice exists and is allocatable, but the screen's default filters (date range, status, entity, period) exclude it. Fix is to widen or expose the filters. Data problem: there genuinely is no matching outstanding invoice, because it's already fully allocated, was written off, sits under a different entity, or was never raised. Fix is to tell the user that clearly rather than showing an empty list. Filters. Filters on the screen should be visible and adjustable, with the current filter state shown so users can see what's being excluded. A way to search across all invoices for the account, ignoring date defaults, would cover most of the reported cases. Empty state. When no invoices are returned, the screen says why — "no outstanding invoices for this account", "3 invoices excluded by date filter", and so on. Silent empty results are what drives the re-keying workaround. No duplication. The original receipt is allocated, not copied. Allocation doesn't create a second receipt record under any path through this screen. Ledger correctness. Allocating a historical receipt moves it from unallocated to allocated against the invoice. It shouldn't create a new cash posting, change the receipt's original date or value, or restate a closed period. Where the receipt sits in a closed period, the allocation needs to post per whatever the agreed accounting treatment is, which is an open question below.

Contract Variations & Extensions Automation

Extend/modify contracts without rebuilding Update budgets, mileage, and repayments Auto-update payroll and finance schedules AI-validated audit trails Pre-fill employer/employee letters, attachments

Reporting platform

Details TBC. We are looking to combine a lot of your requests into a Reporting Platform which would enable you to create custom reports, save them, share them and generate dashboards all inside Catch-e.

Pre-Populate Default Values on Key Fields

Auto-populate contract start dates, pay cycles and propagate across related screens where possible to reduce manual entry, prevent data errors, and ensure consistent behaviour across all modules. These rules reduce manual entry, prevent data errors, and ensure consistent behaviour across all modules. Contract & Finance Defaults Default Contract Start Date: Auto-populate based on quoting workflow or employer configuration. Default Pay Cycle: Prepopulate based on the most common or most recent employer pay cycle; fully editable. Report Finance Payments (Default = TRUE): The Checkbox on the Finance tab is preselected by default and is editable, with an audit trail. Payment Start Date Deferment Rules: Determined by Business Rules Engine (employer-specific rules, delivery date, rego status, payroll cycle), with full explainability. Payment Total Consistency Rule: Total Payments (initial + ongoing payments) must equal the Finance tab payment code totals before contract approval. Discrepancies must be flagged and corrected. Vehicle Tab Defaults VIN → Registration (Rego) Prepopulation: Auto-populate registration number, expiry, model confirmation from VIN/rego services (PPSR/NEVDIS). Default Rego Expiry: Default to Contract Start Date + 1 day for new vehicles. Insurance Defaults Master Insurance Policy Expiry: Tenant-set onboarding field; applied automatically to all leases.

Consolidated Invoicing for Non-Novated Clients

Problem Catch-e currently generates separate invoices per charge type for non-novated fleet clients — typically one for lease rentals, one for recharges, and one for fuel and tolls. For small clients this is a minor inconvenience, but for larger clients the volume becomes unwieldy. One current example: a client invoiced by cost centre across ~100 vehicles and 5 cost centres receives approximately 15 separate invoices every month (3 charge-type invoices × 5 cost centres), each of which is likely lengthy given the vehicle count. This creates unnecessary administrative burden for the client's AP team (reconciling and processing many documents instead of one), increases the risk of processing errors or missed invoices, and reflects poorly on Catch-e's invoicing experience relative to what a large enterprise client would expect from a mature platform. Current Behaviour Invoices are generated and issued separately by charge type (lease rentals / recharges / fuel & tolls), and where a client is set up for cost-centre-based invoicing, this multiplies further — one set of charge-type invoices per cost centre. There is currently no mechanism to consolidate these into a single invoice per client, or per cost centre, across charge types. Proposed Improvement Introduce the ability to consolidate multiple charge types into a single invoice per billing entity (client or cost centre), while retaining itemised detail within that invoice so the underlying breakdown (lease rental vs recharge vs fuel/tolls) remains transparent for reconciliation. This should be configurable per client rather than a global behaviour change, since some clients may have accounting or reconciliation processes built around receiving separate invoices by charge type (e.g. different GL coding, separate approval workflows, or separate payment terms/timing for fuel vs lease). Suggested Scope / Considerations Configuration option at client level (and potentially cost-centre level) to select "combined" vs "separate" invoicing by charge type Consolidated invoice should clearly section/subtotal by charge type so nothing is lost in translation for clients who rely on that breakdown for internal coding Where cost-centre invoicing is used, confirm whether consolidation should also allow combining across cost centres into one client-level invoice, or just combining charge types within each cost centre (the latter would take the example client from 15 invoices to 5) Consider impact on existing integrations/exports that may key off invoice type (e.g. if downstream finance systems expect separate invoice numbers per charge type) Numbering/referencing convention for combined invoices, and how this interacts with existing invoice numbering sequences Migration path for existing clients — likely opt-in rather than retrofitted automatically Any GST/tax reporting implications of combining charge types that may currently be treated distinctly

Integrate Pepper Money Interface with Catch-e

Submit and manage Pepper Money applications directly within Catch-e to streamline finance processing, reduce manual work, and receive faster approval decisions for customers.

Implement Supplier Payments ABA File Generation

Generate an ABA payment file for supplier payments and driver reimbursements. Select approved payments and export them in a bank‑ready ABA format. Validate bank details to prevent errors. Download and store the ABA file securely. Support fast and efficient bulk payment processing.

Expand Standard Reporting library

Description: To reduce the need for bespoke report development and improve self-service reporting, expand the standard report library to include a number of commonly requested reports. Proposed reports: Debtors Report Invoiced vs Receipted Report Current Funds Available Report Finance Budget vs Payments Report Registration Due Next Month Report Business value: Reduces reliance on custom report requests. Improves access to key financial and operational data. Provides greater consistency in reporting across customers. Decreases turnaround time for common reporting requirements. Enhances the value of the standard reporting suite. Expected outcome: Users can access these reports directly from the standard report library without requiring bespoke development or support intervention.

Support Dual Payroll Dates for Bi-Monthly Pay Cycles

Bi-Monthly pay cycles rely on a single stored payroll date, with the second payroll date being assumed by the system. This can lead to inconsistencies when generating and rebuilding budget, payroll, and billing schedules, particularly when customer payroll arrangements do not align with the system's assumptions. To improve accuracy and flexibility, introduce support for two explicitly stored payroll dates for Bi-Monthly pay cycles and ensure both dates are used consistently across all related processes. This enhancement should allow administrators to configure and maintain two distinct payroll dates, require both dates to be populated, prevent duplicate day selections, and make the second payroll date available wherever payroll cycle defaults are configured. Budget date generation, billing schedules, contract processing, employee budget creation, and any schedule rebuild processes should use both stored payroll dates to ensure consistent outcomes. The solution should eliminate the need for system-generated assumptions, reduce manual corrections, improve forecasting and invoicing accuracy, and better support customer-specific payroll arrangements, while ensuring all non-Bi-Monthly pay cycle functionality remains unchanged and unaffected

Intelligent Receipt and Document Recognition (OCR)

Targeted initially at receipts and allowing easy upload through the drivers portal, its envisioned that this capability would be applied more broadly to documents upload in other modules at a later stage. OCR across PDF/JPG/PNG/HEIC/mobile formats Detect invalid photos (faces, non-receipts) Auto populate relevant fields within screens directly from receipt or document Auto-approve claims under $80 GST inclusive after receipt is validated Funds Sufficiency Check: Ensure the driver account has enough money before auto-approval Duplicate/fraud detection Agentic Expense Validator: AI-based validation pipeline Full audit trail and explainable AI decision logs

Employer Portal for Payroll

Problem Statement: Today, employers have limited visibility into changes to employee payroll deductions, particularly when a novated lease or vehicle usage deviates from the original assumptions (e.g., higher kilometres, servicing, or running costs). These variations are typically identified late and communicated through manual reports, emails, or escalations, requiring employer intervention outside normal payroll workflows. This results in delayed approvals, reactive payroll adjustments, additional coordination effort, and avoidable friction between employers, FMOs, and employees. Goal: Provide employers with a role-appropriate portal that gives them early visibility, approval control, and automated payroll alignment for salary packaging and novated lease variations—allowing changes to be approved and applied cleanly, predictably, and with minimal manual intervention. Key Capabilities Proactive notification of payment variations Employers are notified when higher vehicle usage or cost changes will result in a payroll deduction variation, before the change is applied. Approval workflows for variations Employers can review and approve (or query) proposed payroll changes directly in the portal, with full context and audit trail. Payroll system integration Once approved, variations can be automatically passed to the employer’s payroll system, removing the need for manual re-entry or follow-up. Ongoing visibility and oversight Employers can view current balances, funding position, upcoming payroll impacts, and historical changes in one place. Key Benefits Early visibility into cost and payroll impacts, reducing surprises Faster, cleaner payroll adjustments with fewer errors Reduced manual coordination between employers, FMOs, and support teams Improved employer confidence and control without increasing administrative burden Preserved service model, with FMOs retaining ownership of customer relationships

Driver App

The Driver Portal upgrade brings novated lease management into a single mobile app. Drivers can see where their lease is up to, what they have set aside from their pay, what they are spending by category, and what their next car could look like, all from their phone. The goal is to give drivers control and clarity and to remove the friction of managing a novated lease. The app is fully customisable per customer, so branding, colours, logo, and naming can be configured. Launch and sign-in Drivers sign in with either their email or mobile number, then verify with a biometric scan or a one-time code sent to their mobile. There are no passwords to remember, and the account stays secure. Sign-in drops the driver straight into the home dashboard. Home dashboard The dashboard is the hub of the app. It shows where the lease is up to, how much the driver has set aside from their net pay, and a summary of their active vehicle. An insight carousel across the top rotates through timely prompts so useful information surfaces without the driver going looking. A notification bell carries an unread indicator when something needs attention. Quick actions cover the everyday tasks: log kilometres, add a claim, ask Lily, and refer a friend. From the dashboard, drivers can jump straight into their lease, statements, claims, upgrade options, and maintenance. Budget and spend management Each running cost has its own budget, including fuel, tyres, and servicing. Live spend is shown against each category with a simple over or under indicator. Tapping a category opens the transactions behind it for full transparency. A Top up option uses AI to rebalance the budget, lifting only the categories that are over budget and leaving the rest alone, with a clear summary of what changed and why. Because any budget change affects take-home pay, a pay-impact preview is shown before anything is committed. Drive and vehicle tracking Drivers log odometer readings in a moment, and every reading is kept as a full history. From those readings, the app projects annual kilometres and forecasts where the driver will land by the end of the lease year, which matters because kilometres drive the whole lease calculation. When a service is coming due,

Inter-Contract Funds Transfer

Transfer balances between contracts for the same driver/employer Transfer validation (balances, liabilities, holds, payroll locks) Approval workflows and reversal windows Ledger/journal creation; events via API Inclusion in reconciliation and cashflow reporting RBAC to restrict initiators/approvers

GST Status Flags & Splits

Add explicit “GST Included” / “GST Separate” flags on every expense. Support split-expense modelling. Display flags in UI, APIs, exports, and Xero/MYOB integrations. Auto-backfill where derivable.

Integrate Metro Finance Interface with Catch-e

Submit and manage Metro Finance applications directly within Catch-e to streamline finance processing, reduce manual work, and receive faster approval decisions for customers.

Salary Packaging

Self-Service System Lock Management

When a record gets locked, administrators can't clear the lock themselves. Every stuck record means raising a support request and waiting. That's slow for the user who's blocked, it's avoidable load on the support team, and for something time-sensitive it stops work outright. The underlying cause is worth separating from the symptom. Locks that clear themselves properly shouldn't need clearing at all — if admins are regularly raising tickets for this, either locks are being left behind by sessions that ended badly, or the timeout is too generous, or both. The self-service tool is the right fix, but it may not be the only one. Objective Give administrators a safe, audited way to see locked records and release locks without going through support. In scope An admin-accessible view of currently locked records Ability to release a lock from that view Visibility of who holds the lock and since when Audit trail on every release Out of scope Changing the locking mechanism itself Letting non-admin users clear locks, including their own Functional requirements Confirm what kind of lock this is. Before building anything, engineering confirms what's actually being cleared: an edit lock held while a user has a record open, a stale lock left behind by a dropped session, a batch or process lock, or something else. Different lock types carry different risks when force-released, and the answer changes how much protection the screen needs. Locked records view. Admins get a screen listing currently locked records. For each one: the record and its type, the user holding the lock, when the lock was taken, and how long it's been held. Filterable and searchable, so an admin chasing a specific record can find it rather than scrolling. Release. Admin selects one or more locks and releases them. The record returns to normal editable state. Guard against data loss. This is the part that needs care. If the lock holder genuinely still has the record open and unsaved changes in front of them, releasing the lock underneath them can lose their work or let two people save over each other. Options, in rough order of effort: Show lock age prominently and let the admin judge Warn harder on locks younger than some threshold, on the assumption those sessions may still be live Detect whether the holding session is actually still active and treat live sessions differently from dead ones Notify the lock holder when their lock is released Worth deciding how much of this we want before build, rather than adding it after the first incident. Stale locks. If the diagnosis shows most of these are abandoned locks from dropped sessions, an automatic timeout that clears them without admin involvement would remov

Contract APIs

The development of Contract APIs transform Catch‑e into a more open, scalable, and integration-friendly platform, enabling efficient contract processing while supporting innovation, partner connectivity, and superior user experiences.

Suite of Approvals APIs

Provide a comprehensive Approvals API Suite to support a modern, secure, and scalable way for external systems and internal applications to manage approval workflows programmatically. Currently, approvals are primarily managed through a legacy interface, which limits integration capabilities and creates dependency on manual processes. This enhancement would expose the full approvals lifecycle through REST APIs, enabling organisations to create, maintain, validate, post, and unpost approvals while leveraging the same business rules and controls already used within Catch-e.

Support Bot Integration with Catch-e

Deliver a seamless in‑product support experience by embedding the Featurebase Support Bot directly into Catch‑e. The integration is designed to feel like a natural extension of the platform—providing timely, relevant help based on what users are doing, without adding clutter or distraction. It encourages self‑service and quick issue resolution, improving adoption while reducing reliance on manual support, all while maintaining strong performance and accessibility standards.

JATO Vehicle Data Interface with Catch‑e

Delivers the integration of the JATO vehicle data interface with the Catch‑e platform to enable the automated exchange and consumption of accurate, up‑to‑date vehicle data.