With more information here’s my guess about the words that describe what you’re looking for: a report with all GL transaction entries for an organization within a given time period that shows, and sums, the debit or credit for each transaction entry.
As for the term ‘trial balance report’ and countless other terms like it in the wide world of accounting, my experience is that this level of detail is never adequate, even when accountants are speaking with other accountants… they just like to throw out such terms to developers and others in a form that implies it is common terminology that all insiders know. Accountants love that stuff as much as developers do with technical terms, but just like when developers do this it doesn’t help communication and often causes problems.
People in any domain use all sorts of conflicting and insufficiently precise terms, and this works okay within a company but once you step outside groups of people working closely together, it doesn’t matter how knowledgable the other person is when terminology is not sufficiently specific. This is a core issue with many systems too: the concepts and terminology are not adequately defined and are misused over time which muddies and weakens the concepts until it’s just a big pile of spaghetti.
The odd thing is I don’t see this sort of behavior as much from people who work in logistics and other fields, there is something about accounting where they like to be REALLY vague. A “trial balance”… of what and in what form? The Moqui/Mantle accounting functionality is not the most complete or advanced out there, but there are probably a dozen reports in accounting alone that fit that description.
FWIW, this is only one part of the tools available for tracking down errant GL transactions, and IMO usually not very useful. The reason it is not very useful is that there are other safeguards to prevent the sorts of errors that this sort of report would show. If the entries in each transaction are balanced, then the sum of all of the transactions will necessarily be balanced. This is enforced when each transaction is posted, and it checked during the period closing process. The main way issues like this could come up is direct manipulation of database data… so it is useful but in regular operation if you don’t have people mucking around manually in the database (directly or via the Tools screens) and you don’t have code bugs, then it is unlikely this will help find issues with transaction data.
Anyway, for the sort of trial balance you are describing (by organization and time period across all GL accounts), just use the Find Transaction Entry screen (via the Transaction Entries button on the Accounting => Reports screen). In the find options select an Organization and a date range for the Transaction Date, make sure the columns display are what you want (including the Debit and Credit fields), and off you go.
There is also a “Posted Amount Summary” report that will get similar results and which they might like, but for my part I prefer the much more flexible Transaction Entries screen… it has more find/filter options, column selection options, scheduled report by email options (super handy if they want to check these frequently), and so on.
While looking at that I’d recommend looking at the other reports in the “Transaction Reports” section of the Accounting => Reports screen. For more general accounting activities, not just GL validation, there are other reports to help with more common accounting issues like Invoices and Payments not all lining up, the main business transactions that result in accounting transactions. The ones I’ve used most to help clients track down accounting issues are the Order Issued and Invoiced report, and the Invoice Reconciliation report.