Debt Register — Admin Guide
One Admin tab does three jobs that used to have no screen at all: it connects each balance-sheet debt account to the instrument it belongs to, lets you correct a balance that has drifted, and sets the revolver facility limit your forecast draws against and your covenant test measures.
Before this page existed, a drifted debt balance could only be corrected in the database. That is why all three jobs are on one page rather than three — fixing one of them without the others leaves you in the state described under Why the three panels ship together, which is the exact situation this page was built to end.
For: administrators, with input from whoever owns the debt schedule · Time: ~15 minutes to work through the mapping table once, then a minute whenever an instrument changes · You'll need: your loan agreements to hand for the facility limit, and a reason for any balance correction you record.
How to access
Admin → FP&A → Advanced settings → Debt Register. The tab sits in the FP&A
section's Advanced settings tail, closed until you open it, and the
page is deep-linkable — the active tab is written into the URL as
?tab=debt-register, so you can bookmark it or paste it to a colleague.
Who can open it: CEO, admin, and finance-lead roles can read the page. Only CEO and admin can change anything on it — the mapping, the adjustments, and the facility limit are all write-gated to those two roles. A finance lead sees exactly what an admin sees and cannot save.
What the three cards tell you before you read anything else
| Card | What it means |
|---|---|
| Accounts needing a mapping | Debt accounts with no instrument assigned. If this is 0, the subtitle reads "Every debt account is grouped" and Panel 1 needs nothing from you. Anything above zero means those accounts' balance changes are missing from the financing breakdown. |
| Balance adjustments | How many corrections are on file, and how many event groups they fall into. |
| Revolver facility limit | Either the figure you configured, or a dash. The subtitle is the part that matters: "Engine default — not configured" means the forecast is running on a built-in number, not on yours. |
The third card is the one worth looking at first on a tenant nobody has configured yet — see Panel 3.
Panel 1 — Instrument mapping
Each row is a balance-sheet line item classified in the Debt section. You choose, from a dropdown, which instrument type that account belongs to. The forecast groups financing activity by this field; an account without one is left out of that grouping.
Under each account's name the page shows its projection method in small monospace type. That is not decoration — the method is what decides whether the mapping can be reconciled to actuals, and it is why two rows with the same status word can mean different things.
The Status column is a badge, and the "What that means" column spells out the consequence for that specific row rather than repeating a generic warning:
| Badge | What it means |
|---|---|
| Wired | Mapped, and this projection method is reconciled to actuals at the close boundary. This is the finished state. |
| Mapped, not reconciled | Mapped and grouped correctly, but this projection method is never reconciled to actuals — the schedule will not be adjusted to match the account's real balance. Not an error; a limit worth knowing. |
| Unmapped | The balance change still reaches the cash-flow statement through its roll-up, but it is absent from the per-instrument financing breakdown and is never reconciled to actuals. |
| Unmapped — scheduled | The more serious one. Invisible to the financing breakdown and never reconciled, on an account whose method expects reconciliation — so a restructuring here can read as a cash payment. Clear these first. |
| Not applicable | Driven by the cash-flow statement rather than by an instrument. The dropdown is deliberately disabled. |
The revolver row is "Not applicable" on purpose — do not try to map it
Accounts projected from the revolver or from the cash-flow statement are skipped by design when the engine groups financing by instrument type, because the revolver is the cash plug. So the page refuses to let you assign one an instrument type, and says why:
"…is projected by
from_revolver, which the financing-by-instrument grouping skips by design (the revolver is the cash plug, modeled vialoc_net_change). Setting an instrument type here would display a mapping the engine never reads. Leave it unmapped."
That refusal is the useful behavior. An operator who "fixed" the revolver row would be introducing an error while believing they were closing one, and the screen would have reassured them by showing a mapping nothing honors.
If a save is refused
Every write on this page refuses rather than silently storing, and the page shows you the server's own sentence instead of a generic "could not save". The three you may meet: an instrument type outside the accepted vocabulary (the message lists the valid values), an account code with no balance-sheet line item, and the revolver refusal above. Read the sentence — it tells you what to do instead.
Panel 2 — Balance adjustments
An adjustment is held until you press Save adjustment, which reads Saving... while it writes.
A balance adjustment is a correction applied to an instrument's balance: a restructuring, a reclassification, or an extra payment the amortization schedule does not know about.
The sign convention, which is the opposite of most people's instinct
POSITIVE reduces the liability (a paydown). NEGATIVE increases it (a draw or new principal).
The page states this above the form, and then echoes the effect of what you have typed, in words, as you type it — "Reduces the balance by $X (paydown)" or "Increases the balance by $X (draw / new principal)". If that sentence does not describe what you mean, change the sign before you save; do not save and work it out afterwards.
Recording an adjustment
Press Add adjustment and fill in:
| Field | Notes |
|---|---|
| Instrument | Chosen from your existing debt instruments; the dropdown shows each one's type. |
| Effective date | Must be a real YYYY-MM-DD date. The form refuses anything else before it reaches the server. |
| Amount | Must be non-zero. Mind the sign convention above. |
| Event group | Optional, and the most load-bearing field on the form. See below. |
| Reason | Optional but strongly recommended — it is what the next person reads. |
Two adjustments on one instrument on one date are normal and allowed: that is the ordinary shape of a correction, and a two-leg reclassification requires its legs to share a date. They sum.
Saving recomputes the debt schedule immediately — there is no separate rebuild step — and the adjustment is stamped with who recorded it.
Event groups, and the rule that decides cash vs non-cash
Use the same event group on both legs when one liability moves into another — an earnout converting to a seller note, a facility being restructured.
Legs that share a group, fall in the same month, span two instrument types, and net to zero are treated as a non-cash reclassification.
All four conditions have to hold. A cash payment made alongside the reclassification belongs outside the group, so that it stays visible on the cash-flow statement.
You do not have to guess whether you got it right. Under the form, the page lists every event group with the engine's own verdict on it, while you are working:
- Green tick — recognized as a non-cash reclassification.
- Amber warning — "will be treated as ordinary cash activity", with the engine's reason, plus the group's month, leg count, instrument types and net amount. A count above the list tells you how many of your groups are in this state.
An amber group is not necessarily wrong — some activity really is cash. It is wrong when you intended a reclassification, and this is where you find that out, rather than months later when the revolver spikes.
Deleting a leg of a group
Deleting an adjustment that belongs to a group will warn you if legs remain:
"N leg(s) remain in event group '…'. A group only counts as a non-cash reclassification while its legs still net to zero across two instrument types — re-check the group."
Deleting one leg of a netting pair silently converts a recognized non-cash reclassification into ordinary cash activity. Take the warning seriously.
One button, two labels: the Add adjustment button becomes Cancel once
the form is open. So there is no separate Cancel to hunt for — press
the same button again to close the form without recording an adjustment.
Covenant Scope — which debt counts toward DSCR and Leverage
Admin → FP&A → Advanced settings → Covenant Scope
This setting decides whether Arcvue reports a covenant breach. It names the instrument types that count toward your DSCR and Leverage calculations, and every covenant measurement in the product reads it.
It is not a display preference. Re-scoping it changes the numbers: on a copy of a real tenant, changing this moved 10 of 12 covenant measurements and flipped DSCR status in both forecast years.
The screen makes the choice visible; it cannot make it for you
Which instrument types should count is a question about your credit agreement, not about Arcvue. Agreements define leverage differently — many really are senior or bank-debt only, which is what the platform default assumes, and plenty are not. The answer belongs to whoever holds the agreement. Read the definition in your document, then set this to match it.
If you are not sure, leave the default and ask your lender or counsel what the agreement's leverage definition includes. A covenant computed on the wrong scope is worse than one you have not computed, because it looks authoritative.
Panel 3 — Revolver facility limit
This is the ceiling the forecast draws against and the figure the covenant test measures. Until it is set here, the model runs on a built-in default.
Enter the limit and press Save. It must be greater than zero — a zero or negative cap would report every month as a breach, and the server refuses it with that reason.
Two warnings can appear, and they mean different things:
-
Nothing configured. The panel names the built-in default the forecast is using and says the important part out loud: "That is a real number driving real covenant tests — it is not an empty field." An unconfigured facility limit is not a blank; it is someone else's number. If you save a limit here and the forecast had been on the default, the confirmation tells you so.
-
It does not match the revolver's own record. The panel names both figures. This matters because the debt schedule reads the instrument's facility limit while the covenant test reads this one — so the two will disagree about when a breach occurs. Reconcile them; do not leave the disagreement standing.
Why the three panels ship together
A worked example, because it explains the whole page in one paragraph.
An earnout converts to a seller note. The conversion is recorded correctly in all three of the places that hold it — the instrument register, the balance adjustments, and the debt schedule. The balance sheet nevertheless shows the line of credit spiking by the full amount of the note in the month of the conversion. Nothing was mis-typed. The cause is that no balance-sheet account carried the seller-note instrument type, so the extinguishment of the earnout read as a cash payout, and the revolver was drawn to fund a payment nobody made.
Being able to map an instrument type without also being able to correct a drifted balance would leave you in exactly that state. So the mapping, the corrections and the facility limit are one page.
When something looks wrong
| Symptom | Where to look |
|---|---|
| The revolver spikes in a month you did not expect | Panel 1 — look for Unmapped — scheduled rows, and check whether the instrument involved in that month's activity has a mapped balance-sheet account. |
| A reclassification is showing up as cash | Panel 2 — find the event group and read its verdict. Check all four conditions: same group, same month, two instrument types, nets to zero. |
| A covenant breach appears in a month the debt schedule thinks is fine | Panel 3 — the two-figures warning. The schedule and the covenant test are reading different limits. |
| The financing breakdown is missing an account's activity | Panel 1 — that account is unmapped, unless its badge is Not applicable, in which case it is correct. |
| A correction saved but the schedule looks unchanged | The schedule recomputes on save. If it genuinely did not move, check the sign — a paydown entered as a negative increases the balance. |
| You cannot save anything | You are probably a finance lead rather than an admin. Read access and write access differ on this page. |
| The page says it could not load the debt register | The request failed — this is not a statement about your accounts. Click Retry. Nothing you had entered is lost. |
"No debt accounts" and "Couldn’t load the debt register" mean opposite things, and the remedies are opposite.
"No debt accounts" is a fact about your chart of accounts: the page asked the server, got an answer, and no balance-sheet line item is classified into the Debt section. Act on it — classify the accounts in Configuration.
"Couldn’t load the debt register" is a fact about the request, not about your data. The page never got an answer, so it is not in a position to tell you anything about your accounts. Retry re-runs that one request.
The distinction matters because the first sends you to go classify accounts, and doing that in response to the second is work against a problem you do not have.
One-line summary
Map every debt account to its instrument, correct drift with a signed adjustment (positive reduces the liability), group both legs of a conversion under one event group, and set the facility limit so the forecast and the covenant test read the same ceiling.
Related
- Who is allowed to reach this tab, and why a finance lead can read it but not save → Users, Permissions and Access
- Which accounts are classified into the Debt section in the first place → Configuration you must get right in week one
- What this page configures, from the analyst's side — the debt schedule, covenants and exports: see the Debt & Refinancing guide in the FP&A user guides.