Reporting

Native Financial Reporting Dataset (Contacts ↔ Products ↔ Invoices ↔ Transactions/Refunds)
Request: Enable native custom reporting within HighLevel by linking Contacts to Invoices , Invoice Line Items/Products , and Transactions (payments + refunds), including automatic deduction of successful refunds (including partial refunds). This will allow customers using third-party gateways (e.g., Authorize.net ) where payments are processed through HighLevel to produce accountant/GAAP-ready revenue reporting inside HighLevel, along with executive-level reporting —without exporting to external BI tools. ### Problem Today, accurate financial reporting requires stitching together multiple objects (products / invoices / transactions) that are not natively joinable in reporting. This produces incorrect “net collections” because refunds appear as net-positive revenue or are separated from payment totals, forcing teams into brittle exports, spreadsheets, and custom pipelines. For organizations operating under BAA/HIPAA constraints , popular third-party reporting connectors (Coupler/Windsor/Dataddo) are not viable, leaving only custom AWS/Power BI integrations and manual reconciliation. ### Who This Helps Teams using Authorize.net and similar gateways where payments/refunds flow through HighLevel Healthcare clinics and any organization under BAA/HIPAA Agencies supporting HIPAA-bound clients Any customer needing accountant-ready collections/refund reporting ### Desired Outcome Provide a reporting-ready unified data model (view/dataset) supporting JOIN-style reporting across: * Contacts * Invoices (Paid) * Invoice line items / Products * Transactions (Succeeded and Refunds incl. partial refunds; deducted when “successful”) Expose this dataset to: * Custom Reports builder * Dashboard widgets * CSV exports (accounting workflows) ### Required Use Cases (Examples) A) Net Collections (Accountant Report): total collections minus successful refunds , date-filtered, exportable, accurate even when refunds occur later B) Gross Collections Net of Refunds Over Time: day/week/month trendlines; net = payments – successful refunds C) Revenue Trendlines by Date Filter: weekly/monthly rollups (optional filters by location/user) D) Top Paying Customers: ranked by net revenue within a date range E) Revenue by Product: net revenue by product/line item within a date range; supports bundles/packages as line items
0
·
Enhancement
Addition of a "Cost" column to enhance visibility into business performance
Small businesses we've worked with have said they do not have the skills or resources to leverage a SW integration with, say, QuickBooks. While GHL already tracks revenue (when products are sold), adding a cost column would help more fully track and run their business on GHL. Our thoughts on possible implementation are below: -->Light implementation: addition of a static cost column in the 'Inventory' section whereby a user inputs the cost for a given product. This could be updated by the user as product costs change. =>Upon sale of a product, the revenue could be registered from the sale price and the cost could be pulled from the cost recorded in the 'Inventory' section, providing a close measure of profit for each transaction. -->Full implementation: a database that records product cost information as it is entered and timestamps the entry. User could select FIFO (first in, first out) or LIFO (last in, first out) accounting methods to drive the logic determining product cost for a given sale. =>For example: a user buys 5 packs of cinnamon rolls for $3/ea on Jan 1 and 6 packs for $2/ea on Jan 15. GHL records the existence of these in inventory with their stated cost at that time. When the cinnamon roll is purchased on Jan 23rd, the revenue would be recorded based on the sale price and the cost would be recorded either as $3 (FIFO) or as $2 (LIFO) depending on the accounting method selected.
0
·
Enhancement
Load More