Message history
Two tabs on the counterparty screen hold the record of what you sent that customer. Email History lists every email. SMS History lists every text message. Both sit in the Communications group.
The record is written by the platform, not by you. There is no compose box on either tab. Everything listed there was raised by something else in the system.
Email and text messaging are licensed separately, so a tab appears only where your organisation licenses that channel. You may see one tab, both, or neither. See switching features on and off.
What each tab shows
| Tab | What each row holds |
|---|---|
| Email History | The address it went to, the subject, and when it was sent |
| SMS History | The number it went to, the full message text, and when it was sent |
Rows sort newest first.
The tabs cannot load their list yet
Neither tab reads its record today. The record itself is written and kept — every message named below leaves a row behind — but the two tabs ask for it at an address the platform does not answer on, so they come back empty or in error whatever the customer has been sent.
Until that is corrected, treat this article as the description of what is being recorded rather than of what you can read on screen. Where you need the outcome of a particular document now, read it on that document’s own tab: a statement carries its own status, and so does a tax certificate. See statements and tax certificates.
What the tabs will not show
Read these limits before you rely on a tab in a query or a dispute.
| Not shown | What that means for you |
|---|---|
| Whether the message succeeded | A blank sent date means either “not sent yet” or “the send failed”. The tab cannot tell you which |
| Why a send failed | The reason is recorded, but no screen shows it |
| The body of an email | You see the subject only. A text message shows in full |
When you need the outcome of a particular document, read it on that document’s own tab rather than here.
What raises a message
Five things send to a customer today. Nothing else does.
| What was sent | Channel | What raises it | Where you see the outcome |
|---|---|---|---|
| A statement | Automatically, once the document is produced | The account’s Statements tab | |
| A tax certificate | Automatically, once the document is produced | The counterparty’s Tax certificates tab | |
| A statutory default notice | Automatically, once the notice is produced | The account’s Statutory Default tab | |
| A notice that a rate changed | Email and text | You, by selecting Notify holders on the rate-change run | The run’s own screen, per account |
| Proof of a payment received | Email and text | Automatically, when the payment scheme confirms the money landed | The payment instruction |
The first three are email only. There is no text-message version of a statement, a tax certificate, or a default notice.
For the surrounding operations, see statements, tax certificates, chasing arrears, changing a rate and approved beneficiaries.
What never reaches the customer
These leave a record on the customer, and none of them sends anything.
- Alerts, notes and files. An alert shows itself to your own staff when they open the record. It is not a message to the customer. See notes, files and alerts.
- Tasks. A task is work for a colleague. See tasks.
- Anything you print and post. A letter you post by hand leaves no trace on either tab.
- Security emails to your own staff. When a colleague enrols an approval passkey, they are emailed about it. That email is recorded against the colleague, never against a customer. See countersign.
Contact details and consent decide whether anything is sent
Nothing is sent to a customer who has no address on file. For most messages, nothing is sent to a customer who has not opted in either.
Four actions on the counterparty screen govern this:
| Action | What it sets |
|---|---|
| Change Email | The address emails go to |
| Change Mobile Number | The number text messages go to |
| Change Email Consent | Whether the customer accepts email |
| Change SMS Consent | Whether the customer accepts text messages |
Which counterparty types carry these four, and whether a new customer starts opted in or opted out, is your organisation’s configuration.
Consent is not applied evenly
| What was sent | Needs an address | Needs consent |
|---|---|---|
| A statement | Yes | Yes |
| A tax certificate | Yes | Yes |
| A notice that a rate changed | Yes | Yes |
| A statutory default notice | Yes | No |
| Proof of a payment received | Yes, but the beneficiary’s own | No |
A statutory default notice goes to any customer with an email address, whether or not they opted in. That is deliberate: the notice is a legal obligation, not marketing.
Proof of payment reads a different address entirely. It uses the notification contacts held against the beneficiary’s external account, not the counterparty’s own email address and mobile number. Set them on that account, and check them there when a beneficiary says they heard nothing.
Changing a number takes effect from a date
An email address and a mobile number are dated. You can set a new one to take effect from a future date, and the platform sends to whichever one applies on the day. You cannot back-date a change, because that would rewrite where a message you already sent went. See value dating.
Consent works the other way. It is a fact recorded when the customer gives it, not a scheduled change, so it applies from the moment you record it.
What the record proves
The tabs answer one question well: what did we send this customer, to what address, and when.
For a message that matters legally, the stronger proof sits on the document itself rather than on these tabs. A statement, a tax certificate and a default notice each record the channel used, the exact address it went to, and the moment it was sent.
A despatch with no address is refused outright. A record that cannot say where the document went proves nothing, so the platform will not write one.
Only email is proved this way. There is no registered-post channel, so anything you print and post is outside the platform’s evidence entirely. The standards register row National Credit Act 34 of 2005 (South Africa) §130(1) — when enforcement may begin records exactly that, and it is why the row reads Partial. Know it before you rely on the platform in an enforcement.
Where the record can be wrong
Two honest gaps, both narrow:
- A message can go out and the record be lost, if the platform stops between sending and saving. The retry then sends a second copy.
- A message can arrive but be recorded as failed, if the sending service accepts it and the confirmation never comes back.
Both are rare and both are known. Neither is silently papered over: what you see is what the platform believes happened, not a guess.
In a training or test environment nothing actually leaves the building, and the record still reads as sent. Only your live environment sends for real.
Sending the same thing again
Neither tab has a resend action. You cannot re-send a message from the message history.
To send a document again, go back to the document.
| What you want to send again | What you do |
|---|---|
| A tax certificate | Issue the same tax year again on the Tax certificates tab |
| A statement | Open the document and send it yourself. There is no route to email it again |
| A statutory default notice | Open the document and send it yourself |
| A notice that a rate changed | Select Notify holders again on the rate-change run |
Where a document has no route back, download it from its own tab and send it your own way. Then leave a note on the record saying you did, because the platform cannot record a send it did not make. See notes, files and alerts.
Worked example
Alex banks with Woodgrove Bank and has an email address on file.
- Alex has opted in to email. A statement is produced and emailed. One row appears on Email History, showing Alex’s address and the moment it went. The statement’s own tab reads Emailed.
- Sam later records that Alex has opted out. The next statement is produced but not emailed. No row appears on Email History at all — an opted-out customer leaves no trace of a message that was never attempted. The statement’s own tab stays at Rendered, waiting for Sam to send it by hand.
An empty Email History therefore means one of two things: nothing was ever sent, or the customer never consented. Check the consent before you conclude the platform failed.
A default notice, where consent does not apply
Jordan’s account is 1,000.00 in arrears and eligible for a statutory notice.
- Sam issues the notice. The document is produced and emailed to Jordan’s address on file, whether or not Jordan opted in.
- The notice records the channel as email, and the exact address it went to.
- A row appears on Jordan’s Email History for the same send.
- The statutory waiting period runs from that despatch date, not from the day Sam issued it.
One payment, one message
A payment to a beneficiary settles. The beneficiary has an email address on their notification contacts.
- One proof-of-payment email goes out, and one row appears on the beneficiary’s Email History.
- The payment scheme confirms the same settlement twice, as schemes do. No second email goes out, and no second row appears.
- A payment the scheme rejects notifies nobody at all. The beneficiary hears about money that landed, never about money that did not.