In my experience, this is really use-case dependent (the data structure/table definitions part of the discussion). For example, depending on business type, one may need separate tables for purchases and sales if running a "mercantile" business which involves inventory (as apposed to a service business). And if a manufacturing company using raw material with varying replacement costs one faces accounting practices such as LIFO, FIFO, dollar cost averaging, etc. Plus, a business which has replaceable "SKUs" as opposed to one where every lot is unique and never exactly replaced (much of my work is in the latter group).
Handling the accounting side of an inventory-based business has some other things to think about as well. Are receivables always paid in full, and per invoice? Are partial payments of the total allowed? In one of my solutions (laboratory services in three different countries with differing business/revenue department rules) each lab submission is invoiced per record ID (one to several line items per invoice) and each item is paid exactly as invoiced – no exceptions.
That being said, if developing a general ledger, similar to a checkbook register or double-entry accounting, I agree with @pfro Pierre that using one table for "in or out" transactions makes sense.
Finally, regarding repeating fields: I'm not a fan of them, ever since FileMaker gave us more sophisticated tools/structure options. There are a few "hacks" like the Virtual List that use them, but that's a special use-case (and one I typically don't employ) –– oh, and for projects like calendars. Since around FM v3 or so, when FM became a relational database management system (RDBMS) repeating fields have lost much of their appeal/usefulness, but they are still used by some for certain "tricks". They're a tool in the toolbox, but I've never used them in any production solution.
I do deal with "terms" on invoices. Some clients just want a text field to enter verbose terms; some want date fields into which they set a due date field and an amount field. These terms are stored in a child table and can be "Net 10 Days", or 30 or whatever... or can be define over a year or more by date picker, etc. In this latter case, they're defined in a card window or similar so that many entries can be viewed, scrolled, etc. This can get messy as one tracks payments, partial payments, late fees, etc.
