Track guarantee obligations across project milestones

Record whether the guarantee is received or provided, the issuing bank, guarantee number, applicant, beneficiary, currency, amount and underlying contract or order. Identify the purpose, such as performance or advance security, using the actual instrument and agreement.

Store the original or verified authoritative record under appropriate custody controls, with its location and access responsibilities. Keep verification evidence and amendments linked to that identity. A scanned attachment with a plausible bank logo is not, by itself, evidence of authenticity.

The Department of Expenditure's Works Manual, sections 5.1.4 and 5.1.5, addresses verification, custody and monitoring within its public-procurement scope. Use the applicable prescribed process where relevant; do not assume the manual's requirements govern every private contract.

In this fictional example, the original instrument records an expiry date and separate claim-related wording. An amendment changes the expiry. The reviewer must examine what the amendment changes, what it leaves unchanged and how the documents operate together. Do not derive a new claim deadline merely by adding the same number of days.

The register should show amendment received, review pending until the authorised reviewer confirms the revised position. Preserve the previous dates, source clauses and the reviewed outcome. Where wording is ambiguous, route it to the responsible commercial or legal specialist before treating the guarantee as adequately extended.

A reminder can make this review visible before an important date. It cannot decide whether the amendment is legally effective, whether a claim can be made or whether the beneficiary must accept a particular form. Those decisions require the actual documents and appropriate authority.

Useful fields may include issue date, effective date, expiry, relevant claim deadlines or conditions, required contract coverage, requested extension date and next review. Not every instrument expresses these in the same way. Record the source wording and the reviewer's interpretation rather than forcing an unsupported date into every field.

Distinguish the project's desired coverage from the instrument's actual coverage. If the contract milestone moves, the guarantee does not necessarily change with it. The register should flag the mismatch and assign the required review or extension action.

Date calculations need explicit assumptions, including calendar conventions where relevant. If a fixed date is stated in the instrument, preserve it. Do not let a software formula overwrite that date because a validity-in-days field produces a different result.

An advance recovery or completed milestone may support a request to reduce security under the actual terms. It does not automatically reduce the bank's instrument. Track requested amount, approved contractual position, issued amendment and bank confirmation separately.

The same applies to release. A project team may consider its work complete while defects, reconciliation or other obligations remain unresolved. The authorised commercial and finance reviewers need to establish whether the conditions for release have been met. Avoid a rule that closes every guarantee when the project status changes to complete.

ERPNext's Bank Guarantee documentation illustrates an operational register with amount, validity, beneficiary and linked records. It also distinguishes the record from accounting entries. Treat it as a software example; the attachment and qualified review determine the instrument's meaning.

For provided guarantees, finance may need to track margin, deposits, charges and related exposures under its accounting policy. For received guarantees, the project needs assurance that the security required by its agreement is valid and properly controlled. These are related views, but they are not interchangeable balances.

A closed operational entry should have the required release or expiry assessment and supporting evidence. Where cash margin is released, reconcile the actual bank movement and ledger treatment separately. Do not assume that marking a guarantee released has returned funds or posted the correct accounting entry.

Review discrepancies with named owners. A bank confirmation showing a different amount or date should remain an open exception until resolved. Preserve the response and the correction history rather than editing the register to match whichever source is easier to obtain.

Set review lead times through the organisation's approved process, considering the instrument, bank turnaround and project obligations. A generic reminder the day before expiry may be too late to act. Equally, repeated alerts without an owner can make an important exception disappear in routine notifications.

Each alert should state the decision needed: verify an amendment, seek an extension, review coverage after a milestone change, reconcile an amount or consider release. Include the responsible person, delegate and escalation route. Keep delivery of the alert separate from completion of the action.

Test a guarantee whose project date changes, an amendment that leaves ambiguous claim terms, a reduction request not yet issued by the bank and a release without finance reconciliation. The system should show each as a different unresolved state rather than a single expired-or-active flag.

A dependable register allows a new reviewer to reconstruct the instrument, amendments, contractual purpose and final disposition. It supports timely decisions without pretending to make legal or banking judgements automatically.

1. Reconcile one guarantee against the authoritative instrument and all amendments.
2. Separate expiry, claim terms, required coverage and release conditions in the record.
3. Assign decision-based reminders and an authorised escalation route.
4. Confirm the final operational and financial evidence before closing the entry.