FBR Sandbox to Production: A Digital Invoicing Testing Guide

Sandbox testing should prove that your complete invoicing process works—not merely that a server returned HTTP 200. A strong test plan covers data mapping, applicable scenarios, permissions, failure handling, reconciliation and the people who will operate the system.

Keep environments separate

Store sandbox and production credentials separately and restrict access. Use clear visual labels so an operator can see the active environment. Never copy a production token into training material, screenshots, spreadsheets or support messages.

The public technical specification explains that routing is based on the security token and documents different examples for sandbox and production. Treat that distinction as a security control, not a dropdown convenience.

Build a scenario matrix

List the transactions the business genuinely issues. Include buyer registration variations, different product families, tax treatments, discounts, multiple line items, returns or adjustments, and any sector-specific cases. Map each case to the current applicable sandbox scenario rather than testing random payloads.

For every case define the expected result, test data owner, reviewer and evidence to retain. Remove or mask real personal and confidential commercial information when representative synthetic data will serve the purpose.

Test validation and posting separately

Validation helps identify data problems before posting, but a valid response is not itself a posted production invoice. Test both workflows and make their status labels unmistakable. Operators should be able to distinguish draft, validated, submitted, accepted, rejected and awaiting retry.

Capture header-level and item-level responses. A mixed response can require attention to a particular line rather than the whole invoice. Preserve error codes and readable messages with the internal invoice reference.

Test controlled failure

A production-ready workflow must behave safely when authentication fails, a request times out, an external service is unavailable or a response cannot be parsed. Verify that the source invoice is not silently lost and that blind retries cannot create an avoidable duplicate.

Test what happens when reference data changes, a required value is missing, a rate conflicts with a sale type, or an HS/UOM relationship is rejected. Confirm that the user sees a useful correction path.

Conduct user acceptance testing

The people who prepare and review invoices should run the test cases. Ask them to demonstrate how they find a rejected record, correct source data, resubmit under the approved process and reconcile a returned invoice number.

Sign-off should record the version tested, scenarios completed, unresolved limitations, approved users and production decision. Keep a rollback and manual-continuity plan for launch day.

Production readiness checklist

• Current official technical documentation reviewed
• Applicable scenarios passed with evidence
• Credentials stored securely and access approved
• Master data owners confirmed
• Retry and duplicate controls tested
• Daily reconciliation report available
• Support and escalation contacts documented
• Users trained on validation and response status

Review the latest FBR technical assistance before every material release. This guide is operational guidance, not a guarantee of acceptance or legal advice.