This one isn't all that simple due to your table/relationship structure.
If Expenses and Reservations were records in the same table(and that would have it's own set of design challenges), I'd tell you to base your report layout on that table and pull data from teh Properties table into sub summary layout parts. The resulting report is very flexible.
But that doesn't work given the above relationships.
Base your layout on either Expenses or Reservations. I'd use whichever table usually has the most records for a given month.
In a grand summary layout part, add a Portal to the other child table. Size the portal to have more rows than you ever expect to need for an entire month. Set this portal to slide up and resize the enclosing part. Use global fields and a portal filter to filter the portal to only the month and year specified in your global fields or use the global fields as additional match fields in the relationship used for your portal--this may be necessary depending on the calculations you need to perform for your report.
An alternative to the portal, is to define a report table with fields that correspond to the needed fields in reservations and expenses. Then you import the designated month's records from each into this unified table. This can be simple for some data models and nearly impossible for others. A list view layout based on this report table then offers formatting options difficult to do with a portal.
Thank you Phil for your prompt reply and suggested solution. I will work with the grand summary portal option as it seems the simplier solution.