diff --git a/hledger/hledger.m4.md b/hledger/hledger.m4.md
index 2fff632b4..7c3807b34 100644
--- a/hledger/hledger.m4.md
+++ b/hledger/hledger.m4.md
@@ -4918,12 +4918,6 @@ $ hledger print --forecast --today=2023/4/21
 Here there are no ordinary transactions, so the forecasted transactions begin on the first occurence after today's date.
 (You won't normally use `--today`; it's just to make these examples reproducible.)
 
-## Forecast transaction tags
-
-Note the `generated-transaction` tags added by hledger. They remind that these are temporary forecasted transactions, visible in reports only; and they show which rule was responsible. You can use these if you ever need to match forecast transactions in a query: `tag:generated-transaction`.
-
-(The same tag is also present, hidden, with the name `_generated-transaction`. You could use this to match transactions generated "just now", in a situation where you have others previously generated and saved in the journal.)
-
 ## Forecast reports
 
 Forecast transactions affect all reports, as you would expect. Eg:
@@ -4949,12 +4943,40 @@ Balance changes in 2023-05-01..2023-09-30:
                || $1000  $1000  $1000  $1000  $1000 
 ```
 
+## Forecast transaction tags
+
+The `generated-transaction` tags are added by hledger; they indicate transactions generated by --forecast, and show which rule was responsible. If you ever need to match forecast transactions, you could use `tag:generated-transaction` in a query.
+
+(The same tag is also present, hidden, with the name `_generated-transaction`. In some automation scenarios you might have previously saved forecasted transactions in the journal, and this hidden tag could be used to match the transactions generated "just now".)
+
+## Forecast period, in detail
+
+Forecast start/end dates are chosen so as to do something useful by default in almost all situations, while also being flexible. Here are (with luck) the exact rules, to help with troubleshooting:
+
+The forecast period starts on:
+
+- the later of
+  - the start date in the periodic transaction rule
+  - the start date in `--forecast`'s argument
+- otherwise (if those are not available): the later of
+  - the report start date specified with `-b`/`-p`/`date:`
+  - the day after the latest ordinary transaction in the journal
+- otherwise (if none of these are available): today.
+
+The forecast period ends on:
+
+- the earlier of
+  - the end date in the periodic transaction rule
+  - the end date in `--forecast`'s argument
+- otherwise: the report end date specified with `-e`/`-p`/`date:`
+- otherwise: 180 days (~6 months) from today.
+
 ## Forecast troubleshooting
 When --forecast is not doing what you expect, here are some tips.
 
 Can't see what it's doing ?
 
-- Use `print --forecast`, as above.
+- Test with `print --forecast`.
 
 No forecast transactions are visible ?
 
@@ -4965,8 +4987,8 @@ No forecast transactions are visible ?
 - Check for a future dated ordinary transaction suppressing forecasted transactions.
 - Set an explicit report end date with `-e`, `-p` or `date:`.
 - Add the `-E` flag to encourage display of empty periods/zero transactions.
-- Consult [Forecast period, in detail](#forecast-period-in-detail), below.
-- Check the engine: add the `--debug=N` option, increasing N from 1 to 9 as needed.
+- Consult [Forecast period, in detail](#forecast-period-in-detail) above.
+- Check inside the engine: add the --debug option, eg `--debug=2`.
 
 Forecast transactions are visible, but starting or ending too soon/too late ?
 
@@ -4980,29 +5002,6 @@ A future-dated transaction is making it harder to generate forecast transactions
 - If you have recorded some important future event as an ordinary transaction, and it is interfering with easy --forecast-ing, you could consider making it a (non-recurring) forecast transaction instead. Just insert a `~` before the date and make sure there 2+ spaces after the date. Then it won't suppress other forecast transactions (and you'll have to use `--forecast` to see it).
 -->
 
-## Forecast period, in detail
-
-Forecast start/end dates are chosen so as to do something useful by default in almost all situations, while also being flexible. Here are (with luck) the exact rules, to help with troubleshooting:
-
-The forecast period starts on:
-
-- the later of
-  - the start date in the periodic transaction rule
-  - the start date in `--forecast`'s argument
-- or if neither of the above are available, the later of
-  - the report start date specified with `-b`/`-p`/`date:`
-  - the day after the latest ordinary transaction in the journal
-- or if none of the above are available: today.
-
-The forecast period ends on:
-
-- the earlier of
-  - the end date in the periodic transaction rule
-  - the end date in `--forecast`'s argument
-- or if neither of the above are available
-  - the report end date specified with `-e`/`-p`/`date:`
-- or if none of the above are available: 180 days (~6 months) from today.
-
 # Budgeting
 
 With the balance command's [`--budget` report](#budget-report),