Contact support with safe diagnostics

A useful support request identifies the failed workflow and provides precise, customer-safe evidence. It should not expose credentials or unrelated financial records. Include the screen wording you actually saw; labels and navigation can change between releases.

Prerequisites

• Access to the affected tenant and record.
• An approved support channel for your organization.
• Permission to share the minimum necessary operational data.
• A redaction tool if screenshots contain personal, banking, or invoice details.

Before collecting evidence, reproduce the issue at most once if doing so is safe. Repeated bank authorizations, imports, or reconciliation actions can complicate diagnosis.

Steps

1. State the affected workflow. Choose one primary area: bank authorization, account discovery, transaction sync, issued-invoice CSV import, match confidence, or manual reconciliation.

2. Identify the environment. State whether the tenant is sandbox or production according to the UI. For sandbox bank tests, include whether you selected SI, Personal, and Mock ASPSP. Do not describe a successful sandbox test as production behavior.

3. Provide time context. Include the date, local time, and time zone of the failed action. If you retried, list each attempt separately and identify the first failure.

4. Copy the exact visible error. Paste the customer-facing text as displayed. Do not paraphrase if the original is available. Remove any token, authorization code, or sensitive URL query value before sharing.

5. Describe expected and actual results. For example: “Expected the Personal Mock ASPSP sample transactions after connection; the account appeared active, but Transactions remained empty.”

6. List reproducible steps. Keep them short and ordered. Mention the page, selected options, action, redirect behavior, and where the result appeared.

7. Add workflow-specific state.

   • For banking: connection status, bank or test-institution label, account label, last-sync timestamp, whether account discovery succeeded, and whether manual sync was attempted.
   • For invoice import: sanitized file name, delimiter, row count, mapped total field, created count, duplicate count, and row-error text.
   • For reconciliation: transaction direction, currency, sanitized amount if permitted, issued document kind, open status, confidence band, and whether the transaction is ignored.

8. Use safe record references. Invoice number, transaction code, or connection identifier may help support find the record, but share only what the approved channel allows. Prefer internal record codes over full bank descriptions.

9. Redact screenshots. Remove unrelated customer names, full IBANs, email addresses, addresses, balances, and transactions. Keep the relevant status, timestamp, control, and error visible.

10. Attach a minimal sample only when necessary. For a CSV issue, create a synthetic file with one or two rows that reproduces the parsing or mapping problem. Do not send an entire customer export when a minimal sample is sufficient.

11. Say what has already been tried. Mention a fresh authorization, one manual sync, corrected mapping, or manual candidate search. Include whether disconnecting has already occurred; imported transactions remain after disconnect.

12. Review before sending. Search the request and attachments for secrets, hidden spreadsheet metadata, and unrelated personal data.

Expected result

Support receives enough context to identify the tenant, release stage, workflow, failure time, visible state, and reproduction path without requesting credentials. The report distinguishes a bank connection problem from a transaction sync issue, and an import problem from a matching-scope decision.

A concise template is:

1. Tenant and mode:
2. Workflow:
3. Attempt time and time zone:
4. Steps:
5. Expected result:
6. Actual result and exact error:
7. Relevant status or record codes:
8. Troubleshooting already attempted:
9. Sanitized attachment:

Edge cases and troubleshooting

• The error disappeared: send the original time, exact text if retained, and current state. Do not force another failure solely to obtain a screenshot.
• The UI says active but no transactions exist: report authorization and synchronization as separate stages. Include discovered accounts and last-sync state.
• Only some CSV rows failed: provide the row-error messages and a synthetic failing row, plus counts for successful, duplicate, and failed rows.
• A match looks wrong: include direction, document kind, confidence band, and the signals that conflict. Avoid sending the full bank statement.
• You cannot determine tenant mode: say so and attach a redacted connection-dialog screenshot.
• The issue concerns production availability: request explicit confirmation. Do not infer availability from documentation or sandbox behavior.

Security and sandbox notes

Never send:

• bank usernames or passwords;
• one-time passwords or MFA codes;
• Enable Banking authorization codes;
• private keys, certificates, API keys, access tokens, session cookies, or secret configuration;
• an unredacted bank statement or customer invoice set.

Sandbox is still tenant data. Use synthetic records and protect screenshots. Do not infer any certification or assurance status from this article. Follow your organization’s incident, retention, and secure-transfer policies.

Next step

For bank-specific checks before escalating, follow Troubleshoot a bank connection. For a matching issue, complete the checklist in Resolve an unmatched transaction.

Updated 6 August 2026

Was this article helpful?

Feedback helps us improve the next version of this guide.

Yes Not yet Tell us what is missing