I've written a number of accounting applications over the years. All of them have a single transactions table which, depending on requirements, has either a single value column with a method or perhaps another field to identify whether it is a debit or credit or it has separate debit and credit fields. Both structures link back to customer/supplier, nominal codes etc.
The only time I might need to use a union query is if my transaction table structure is something like
dr account
cr account
value
(plus other fields of course)
where I need a list of all transactions for something like a detailed nominal ledger report - but it only needs two selects, the first to collect the dr accounts, the second the cr.
The alternative (and my preference as it retains the use of indexing) is to use a counter table in a cartesian relationship with the transactions table (i.e. no join) counter table is limited to 2 records (e.g. 0 and 1) and calculated values for fields that require it e.g. iif(countvalue,dr account, cr account), iif(countvalue, value, value*-1).
Similar principle can be used to create opening and closing balances within the same query (requires 3 or 4 records from the counter table and changed to an aggregate query)
The only other time I can envisage needing a union query is where a single report needs to be collated to provide a 'cascading view' - At the top - a short highlight , followed by summary by categories, then sub categories then detail. etc. However I see this as a 'quick and dirty' to get the job done in a query to export to excel. Could be done using a report with sub reports for example. Or longer term, include some 'reporting' fields in the nominal codes table with calculated values as indicated above.