Oracle Customer Account Site Testing
A customer account site is where Oracle Receivables decides where a transaction ships, where it bills, and which defaults it inherits. Bill-to and ship-to sites carry their own business purpose, payment terms and method defaults, tax registration, and status — and every invoice, receipt, and dunning letter depends on the right site being selected. Get site configuration wrong and the defect doesn't stay contained; it shows up as a misbilled customer, a missed tax registration, or a statement sent to a deactivated address.
This page is a practical guide to testing customer account sites specifically — creation, business purpose, primary designation, defaulting behavior, and deactivation. It sits under the Oracle Accounts Receivable (AR) Testing Tool hub and complements, rather than duplicates, customer master testing.
What Is Customer Account Site Testing in Oracle Receivables?
In Oracle Fusion Receivables, a customer account can carry one or more sites — address-anchored records that determine where a transaction bills and ships. Each site is assigned one or more business purposes (Bill-To, Ship-To, or both), can be designated primary for its purpose, and can carry its own payment terms, payment method, tax registration, and credit limit that override the customer-level default. Site status — active or inactive — controls whether the site remains usable for new transactions.
Site testing verifies that these site-level attributes are configured correctly and, critically, that they default correctly onto invoices, receipts, and correspondence. A site record that is technically valid but never defaults onto the transaction it should — or defaults onto the wrong one — is a defect that surfaces downstream, often after the transaction has already posted.
Scope note. This page covers site-level configuration — bill-to/ship-to sites, business purpose, site-level payment terms and method, site tax registration, and site status. It does not cover the customer master record itself — profile class, overall credit limit, customer-level defaults, and account hierarchy are covered on the Oracle Customer Testing page. Treat that page as the account-level control and this one as the site-level control that sits beneath it.
Customer vs Customer-Site Responsibility
A common source of untested gaps is assuming an attribute lives at the customer level when Oracle actually resolves it at the site level, or vice versa. This table draws the line.
| Attribute | Owned by customer master | Owned by customer account site |
|---|---|---|
| Legal name, DUNS, tax registration ID | Yes — account-level identity | No |
| Overall credit limit | Yes — customer-level ceiling | Site-level override permitted |
| Default payment terms | Yes — account default | Site-level override permitted |
| Default payment method | Yes — account default | Site-level default permitted |
| Bill-to / ship-to addresses | No | Yes — site is the address record |
| Business purpose | No | Yes — assigned per site |
| Primary bill-to / ship-to designation | No | Yes — flagged per site |
| Tax registration | Account-level default possible | Site-level registration used for invoicing |
| Status (active/inactive) | Customer account status | Independent site status |
| Dunning / collections plan | Yes — account default | Site-level override permitted |
Why Testing Customer Account Sites Matters
Site records are quiet infrastructure — nobody notices them until a transaction defaults to the wrong one. Because sites drive billing address, tax, and payment defaults simultaneously, a single misconfigured site can touch every transaction booked against it.
| Risk | Example | Potential impact | Testing response |
|---|---|---|---|
| Wrong site defaults to invoice | Non-primary site selected by AutoInvoice | Invoice billed to wrong address/contact | Assert primary-site defaulting on new transactions |
| Primary flag misapplied | Two sites both flagged primary, or none | Ambiguous defaulting, statements to wrong site | Negative test on primary re-designation |
| Payment terms override ignored | Site term set but customer default still applies | Incorrect due dates; DSO distortion | Compare site override vs customer default on invoice |
| Tax registration missing | Site created without required registration | Tax under/over-charged; compliance exposure | Validate tax registration required at site creation |
| Deactivation with open balance | Site inactivated while invoices remain open | Collections gap; unreachable balance | Test deactivation against open-item precondition |
| Duplicate site created | Same address entered as a second site | Fragmented balance; reporting error | Negative test on duplicate-address creation |
| Cross-business-unit leakage | Site visible/usable outside its owning BU | Data segregation and SOX concern | Test site access under BU-scoped roles |
| Merge loses history | Duplicate sites merged without full history | Incomplete audit trail | Verify transaction history post-merge |
| Import creates malformed sites | FBDI load skips required flags | Downstream billing/tax defects | Validate imported sites against manual-entry baseline |
| Silent behavior change | Quarterly update alters defaulting logic | Undetected control drift | Release-aware regression on site defaulting |
The Customer Account Site Lifecycle
A site's life runs from creation on an existing customer account through to deactivation, with defaulting behavior operating continuously in between.
Site lifecycle sequence
- Trigger: a new bill-to or ship-to relationship for an existing customer account, entered manually, via FBDI import, or through REST.
- Key checks: business purpose correctly assigned, primary designation set where required, payment terms/method and tax registration resolved, status active.
- Decision point: whether the site becomes primary for its purpose — this determines what defaults onto future transactions until changed.
- In-life use: the site is selected — by default or explicitly — on invoices, receipts, and correspondence for as long as it remains active.
- Deactivation: status set inactive once the site is no longer used; open balances and in-flight transactions must be handled before or around deactivation.
- Downstream impact: invoice defaulting, receipt application, tax calculation, GL account derivation, and dunning correspondence all read from the site.
Suggested visual: a lifecycle diagram of site states (created → active → primary → inactive) for the web team to produce.
Site-Control Matrix
The dimensions a complete customer account site test suite must cover, with automation suitability and priority.
| Test area | What must be validated | Example scenario | Automation | Priority |
|---|---|---|---|---|
| Site creation (bill-to) | New site created with correct address and purpose | Bill-to site added to existing account | High | High |
| Site creation (ship-to) | New site created with correct address and purpose | Ship-to site added to existing account | High | High |
| Business purpose | Purpose assignment and later change behave correctly | Site purpose changed from bill-to only to both | High | Medium |
| Primary designation | Only one site primary per purpose at a time | New primary bill-to clears prior flag | High | High |
| Payment terms override | Site term supersedes customer default | Site net-45 overrides customer net-30 | High | High |
| Payment method default | Site method defaults onto transactions | Site defaults to wire vs customer's check | High | Medium |
| Tax registration | Registration applied and drives tax calculation | Site registration used on invoice tax line | High | High |
| Credit limit override | Site limit applied instead of customer limit | Site-specific limit enforced at order entry | Medium | Medium |
| Status / deactivation | Deactivation respects open-item preconditions | Deactivation attempted with open invoices | High | High |
| Duplicate detection | Matching address/purpose flagged or blocked | Second site created at same address | Medium | Medium |
| Import / API creation | FBDI and REST-created sites match UI baseline | Bulk site load via FBDI | High | Medium |
| Cross-BU access | Site visibility respects business-unit security | User from BU B cannot see BU A site | High | High |
| Defaulting to invoice/receipt | Correct site selected on new transactions | Primary ship-to defaults on new order-to-invoice flow | High | High |
| GL account default | AutoAccounting derives correct account from site | Revenue account varies by site segment | Medium | Medium |
| Role-based access | Only privileged roles create/edit sites | Read-only role attempts site edit | Medium | High |
| Regression / release | Site behavior unchanged after an update | Re-run pack after quarterly update | High | High |
Oracle Customer Account Site Test Scenarios
A representative set of 32 Oracle Fusion customer account site scenarios — creation, business purpose, defaulting, status, integration, and regression. Test IDs use the AR-SITE prefix.
| ID | Scenario | Preconditions | Expected result | Pri | Auto |
|---|---|---|---|---|---|
| AR-SITE-001 | Create bill-to site | Customer account exists, valid address | Site created with Bill-To purpose, active | H | Y |
| AR-SITE-002 | Create ship-to site | Customer account exists, valid address | Site created with Ship-To purpose, active | H | Y |
| AR-SITE-003 | Create site with both business purposes | Customer account exists | Single site usable as both bill-to and ship-to | H | Y |
| AR-SITE-004 | Add multiple sites to one account | Customer account exists | All sites listed and independently addressable | H | Y |
| AR-SITE-005 | Designate primary bill-to site | Multiple bill-to sites exist | New site primary; prior primary flag cleared | H | Y |
| AR-SITE-006 | Designate primary ship-to site | Multiple ship-to sites exist | New site primary; prior primary flag cleared | H | Y |
| AR-SITE-007 | Site-level payment terms override | Customer default term set; site term entered | Site term applies on transactions for that site | H | Y |
| AR-SITE-008 | Site-level payment method default | Site method differs from customer default | Transactions default to site payment method | M | Y |
| AR-SITE-009 | Assign tax registration to site | Site created in a taxable jurisdiction | Registration stored and applied to site invoices | H | Y |
| AR-SITE-010 | Apply site-level tax exemption | Exemption certificate on file for site | Tax suppressed on eligible site transactions | M | Y |
| AR-SITE-011 | Activate site | Site created inactive | Status active; site usable in new transactions | M | Y |
| AR-SITE-012 | Deactivate site with no open items | Site has no open invoices or receipts | Site inactive; unavailable for new transactions | H | Y |
| AR-SITE-013 | Deactivate site with open invoices | Site carries open, unpaid invoices | Deactivation blocked or warned; open items still processable | H | Y |
| AR-SITE-014 | Site address validation | New address entered on site | Address validated/normalized per configured rules | M | Y |
| AR-SITE-015 | Assign contact to site | Site exists | Contact linked; available for correspondence | L | Y |
| AR-SITE-016 | Site-level credit limit override | Customer master has a credit limit set | Site limit applies for site-specific transactions | M | P |
| AR-SITE-017 | Site defaults on new invoice | Site designated primary and active | Invoice bill-to/ship-to defaults from site correctly | H | Y |
| AR-SITE-018 | Site used in receipt application | Receipt applied against customer | Receipt applies against correct site-level balance | H | Y |
| AR-SITE-019 | Duplicate site detection | Attempted create matches an existing address/purpose | Duplicate flagged or prevented | M | Y |
| AR-SITE-020 | Create site via FBDI import | Import file with valid site records | Sites created matching file; flags correct | M | Y |
| AR-SITE-021 | Create site via REST API | Valid API payload for site creation | Site created via API matches UI-created equivalent | M | Y |
| AR-SITE-022 | Cross-business-unit site access | Site scoped to BU A; user accesses from BU B | Access denied or scoped per BU security | H | Y |
| AR-SITE-023 | Change site business purpose | Existing bill-to-only site | Purpose updated to include ship-to; both usable | M | Y |
| AR-SITE-024 | Site-level currency default | Site configured with non-ledger currency | Transactions for the site default to site currency | M | Y |
| AR-SITE-025 | Site-level dunning/collections override | Customer dunning plan differs from site override | Site override plan applied at site level | M | P |
| AR-SITE-026 | Site GL account default | AutoAccounting rules reference site attributes | Correct GL account derived for site transaction | H | Y |
| AR-SITE-027 | Site descriptive flexfield attributes | DFF configured on site | Attribute values saved and retrievable | L | Y |
| AR-SITE-028 | Site audit history | Site attribute changed by a user | Change captured with user and timestamp | M | Y |
| AR-SITE-029 | Merge / consolidate duplicate sites | Two sites identified as duplicates | Transaction history consolidated under surviving site | M | P |
| AR-SITE-030 | Role-based site access | Role without site-edit privilege attempts update | Update denied; read-only access enforced | H | P |
| AR-SITE-031 | Site reporting and listing | Multiple sites exist across customers | Report/listing returns accurate site attributes | L | Y |
| AR-SITE-032 | Quarterly-release regression on site behavior | Post-update tenant | Prior creation and defaulting results reproduce | H | Y |
Pri = priority (H/M/L). Auto = automation candidate (Y suitable · P partly, needs role/data setup). Steps summarised; full step detail ships in the downloadable checklist.
Common Customer Account Site Defects
| Defect | Likely cause | Business impact | Recommended test |
|---|---|---|---|
| Wrong site defaults to invoice | Primary flag not honored by defaulting rule | Invoice billed to wrong address/contact | AR-SITE-017 |
| Primary designation not respected | Prior primary flag not cleared on re-designation | Ambiguous defaulting; wrong site used | AR-SITE-005, AR-SITE-006 |
| Payment terms override ignored | Customer default takes precedence unexpectedly | Incorrect due dates; DSO distortion | AR-SITE-007 |
| Tax registration missing or misapplied | Registration not linked to site at creation | Tax under/over-charged; compliance risk | AR-SITE-009, AR-SITE-010 |
| Site deactivated with open balance | No precondition check before deactivation | Collections gap; unreachable balance | AR-SITE-013 |
| Duplicate site created | Weak or bypassed duplicate check | Fragmented balance; reporting error | AR-SITE-019 |
| Cross-BU site leakage | Security profile not scoped to BU | Data segregation and SOX concern | AR-SITE-022 |
| Malformed site from import | FBDI template missing required flags | Downstream billing and tax defects | AR-SITE-020 |
| GL account misderived | AutoAccounting rule doesn't reference site correctly | Wrong revenue account; reconciliation break | AR-SITE-026 |
| Credit limit override not applied | Site limit not read at order/invoice entry | Credit exposure beyond intended limit | AR-SITE-016 |
| Merge loses transaction history | Consolidation process drops linked records | Incomplete audit trail | AR-SITE-029 |
How SyntraFlow Automates Customer Account Site Testing
SyntraFlow drives site creation and defaulting scenarios end-to-end, then asserts the resulting default — not just that the site record was saved.
Site-creation automation
Runs bill-to, ship-to, and dual-purpose site creation through the UI, FBDI, and REST, and compares the results against your expected outcomes.
Default-value validation
Asserts that payment terms, payment method, tax registration, and GL account actually default from the site onto the transaction — the outcome that matters.
Multi-business-unit testing
Exercises site creation and access across business units so cross-BU leakage is caught before it reaches production.
Role-based execution
Runs the same site scenario under different roles to confirm who can create, edit, or deactivate a site.
Customer-to-invoice validation
Follows a site from creation through to the invoice or receipt it defaults onto, confirming the whole chain rather than a single screen.
Oracle Data Vault comparisons
The Oracle Data Vault provisions customers and sites with known attributes so defaulting tests produce predictable, comparable results.
Audit evidence
Captures screenshots, defaulting logs, and execution traces for every run, retained as audit-grade evidence.
Release-impact selection
Runs the site-testing subset a given release actually affects, rather than the full pack every quarter.
Configuration-aware testing
Ties each scenario to the payment-terms, tax, and AutoAccounting configuration that drives it, so a config change re-points the right tests.
A note on capability. Site-creation automation, default-value assertions, role-based execution, and Data Vault provisioning are current platform capabilities. Coverage scoped to your specific business units, payment-terms hierarchy, and tax configuration is configurable during onboarding. Any tenant-specific extension is confirmed at assessment rather than assumed here.
How Site Defaults Flow to Invoices and Receipts
A site's attributes only matter once they default correctly onto a live transaction. This is the defaulting behavior a complete test suite must exercise.
| Defaulting scenario | Source of default | Where it applies | Override / test focus |
|---|---|---|---|
| Bill-to site | Primary bill-to flag on account | New transaction header | Manual override at entry must still be possible |
| Ship-to site | Primary ship-to flag on account | New transaction header/line | Line-level ship-to override supported |
| Payment terms | Site override, else customer default | Invoice header | Confirm precedence order is site-first |
| Payment method | Site default, else customer default | Invoice / receipt | Confirm site default applied at receipt creation |
| Tax registration | Site tax registration record | Invoice tax line | Registration drives correct tax determination |
| GL account | AutoAccounting rule referencing site attributes | Transaction distribution | Validate derived account against expected CCID |
| Currency | Site currency default, else customer default | Transaction header | Confirm site currency honored where configured |
| Credit limit check | Site override, else customer master limit | Order/invoice entry | Confirm site limit enforced when present |
| Dunning correspondence | Site override plan, else account default | Statement/dunning letter selection | Correct site addressed on correspondence |
| Receipt application | Site-level open balance | Receipt application/matching | Receipt reduces the correct site's balance |
Defaulting behavior at invoice creation connects directly to invoice-level testing — see Oracle Invoice Testing for the transaction side of this chain, and Oracle Credit Management Testing for how site-level credit overrides interact with credit checks.
When to Re-Test Customer Account Sites
Site behavior depends on configuration that changes independently of the site records themselves. Retest when these events occur:
| Change event | Risk to site behavior | Recommended regression scope |
|---|---|---|
| Oracle quarterly update | Site defaulting or purpose logic changes | Full site pack, release-scoped |
| Redwood rollout for AR pages | Site create/edit UI changes | UI creation and defaulting cases |
| Payment terms / method configuration change | Override precedence shifts | Terms and method override cases |
| Tax registration rule change | Site tax defaulting changes | Tax registration and exemption cases |
| Credit policy / profile class change | Site credit override behavior shifts | Credit limit override cases |
| AutoAccounting rule change | Site-derived GL account changes | GL account default cases |
| Security role change | Who can create/edit/deactivate a site changes | Role-based access cases |
| New business unit / legal entity | Setup gaps cause cross-BU issues | Cross-BU access + creation cases |
| FBDI template or API contract change | Import/API-created sites diverge from UI | Import and API creation cases |
| Site merge / consolidation event | Transaction history at risk | Merge/consolidation cases |
| Production defect fix | Fix may regress adjacent defaulting | Targeted + smoke site pack |
Customer Account Sites & Oracle Quarterly Releases
Oracle's quarterly updates can change site defaulting without any action on your part — through feature opt-ins, Redwood redesigns of the customer and site pages, or altered precedence between site and customer defaults. Because site defaulting silently drives billing address and tax on every transaction, an unnoticed change compounds quickly.
Rather than re-testing every site scenario on every release, SyntraFlow Release Intelligence narrows the work to what actually changed in your tenant:
- 1.Analyses the Oracle release notes for changes touching Receivables customer and site setup.
- 2.Maps those changes to your configuration — payment terms, tax rules, AutoAccounting.
- 3.Identifies which business units and site types are affected.
- 4.Recommends the specific site test cases to run.
- 5.Prioritises regression execution by risk.
- 6.Tracks test evidence for audit and sign-off.
See how the impact map is built on the Release Impact Analysis page.
Configurations That Drive Site Behavior
A site test is only trustworthy if the configuration behind it is known and stable. These setups determine how a site defaults and behaves — and when they drift between environments, tests pass against the wrong reality.
| Configuration area | Testing impact | Example failure | Recommended validation |
|---|---|---|---|
| Business unit / Receivables system options | Govern site visibility and defaulting scope | Option differs between environments | Cross-BU access cases |
| AutoInvoice defaults | Determine which site is selected on import | Wrong site selected on imported transaction | Defaulting cases via import |
| Payment terms setup | Sets site-vs-customer precedence | Term differs from production | Payment terms override cases |
| Payment method setup | Drives site default payment method | Method not available in lower environment | Payment method default cases |
| Tax registration rules | Govern required registrations by jurisdiction | Registration requirement out of sync | Tax registration cases |
| Customer profile classes (credit) | Set customer-level credit defaults | Profile class differs from prod | Credit limit override cases |
| Collections / dunning setup | Determines which site receives correspondence | Dunning plan mismatch | Dunning override cases |
| AutoAccounting rules | Derive GL account from site attributes | Rule change mis-derives account | GL account default cases |
| Descriptive flexfields | Required attributes on site record | Required DFF differs by environment | Flexfield validation cases |
| Role / security setup | Governs who creates/edits/deactivates sites | Privilege drift between environments | Role-based access cases |
SyntraFlow's Configuration Intelligence compares these setups across environments and flags drift before it corrupts a site test result — so a passing test means the configuration was correct, not just present.
Oracle Customer Account Site Testing Checklist
A practical checklist your team can work through before every go-live and quarterly update. It walks each area a complete site test suite should cover: site assignments and business purpose, site flags including primary designation and status, payment terms and payment method defaults, tax defaults and registration, business-unit access and role scoping, and the evidence and sign-off record that closes each control.
It also maps each item to the AR-SITE scenarios above, so you can turn the checklist directly into an executable pack. Request it as part of a working session with our team.
Customer Account Site Testing Best Practices
Assert the actual default that lands on the transaction, not just that the site record saved.
Test primary-site re-designation explicitly — the prior flag must clear, not just the new one set.
Keep site testing separate from customer master testing so failures are unambiguous.
Cover deactivation against both clean and open-balance preconditions.
Validate site creation through UI, FBDI, and REST — controls must be identical across entry points.
Test cross-business-unit access explicitly to protect data segregation.
Use production-like payment terms, tax rules, and AutoAccounting configuration, not simplified test config.
Follow a site from creation through to the invoice or receipt it defaults onto.
Re-run the site pack on every quarterly update, scoped by release impact.
Capture site attribute changes and defaulting evidence automatically for audit and sign-off.
Include duplicate-detection and merge/consolidation cases in every cycle.
Re-validate coverage after any payment-terms, tax, or security-role change.
Manual vs Generic Automation vs SyntraFlow
For customer account site testing specifically.
| Capability | Manual | Generic automation | SyntraFlow |
|---|---|---|---|
| Oracle site-defaulting awareness | Manual | No | Yes |
| Pre-built site scenarios | No | No | Yes |
| Maintenance effort | Very high | High | Low |
| Self-healing on Redwood | N/A | No | Yes |
| Release-impact analysis | No | No | Yes |
| Configuration awareness | Manual | No | Yes |
| UI + FBDI + API testing | Partial | Partial | Yes |
| Audit-grade evidence | Weak | Partial | Yes |
| Reusability | Low | Medium | High |
Related Oracle Receivables Pages
Customer account sites connect to the rest of the AR suite. Go deeper on adjacent topics:
Oracle AR Testing Tool ⭐
The Receivables testing hub.
Oracle Customer Testing →
Customer master and profile testing.
Oracle Invoice Testing →
Where site defaults land on transactions.
Oracle Credit Management Testing →
Credit checks and site-level overrides.
Oracle ERP Testing Tool →
The full Oracle Fusion testing platform.
Oracle Data Vault →
Test data provisioning for customers and sites.
Frequently Asked Questions
What is a customer account site in Oracle Receivables?
▼
A customer account site is an address-anchored record attached to a customer account that carries a business purpose — bill-to, ship-to, or both — along with its own payment terms, payment method, tax registration, and status. It determines where a transaction bills or ships and what defaults it inherits.
How is site testing different from customer master testing?
▼
Customer master testing covers account-level identity, profile class, and overall credit limit. Site testing covers the address-level records beneath the account — creation, business purpose, primary designation, and the defaults that flow from a site onto a transaction. See the Customer Testing page for the master-record side.
What business purposes can a site have?
▼
A site is typically assigned Bill-To, Ship-To, or both. A single site can carry both purposes, or an account can maintain separate sites for each. Testing should confirm both single-purpose and dual-purpose sites behave correctly when defaulting onto transactions.
How does Oracle default the bill-to and ship-to site on a transaction?
▼
Oracle defaults the site flagged primary for the relevant business purpose, unless the transaction source (manual entry, AutoInvoice, or an integration) overrides it explicitly. Testing must confirm the primary flag drives the default and that manual override remains available.
Can a customer account have more than one primary site?
▼
Not for the same business purpose. An account can have one primary bill-to site and one primary ship-to site simultaneously, but designating a new primary for a given purpose should clear the flag on the prior one — a scenario that must be tested explicitly.
What happens when a site-level payment term differs from the customer-level term?
▼
The site-level override takes precedence for transactions against that site; the customer-level term remains the default for sites without an override. Testing should confirm this precedence explicitly, since a misconfigured hierarchy silently produces the wrong due date.
How is site-level payment method defaulted?
▼
A site can carry its own default payment method, which applies to invoices and receipts against that site ahead of the customer-level default. Testing should confirm the site default is honored at both invoice creation and receipt application.
Does deactivating a site affect open invoices?
▼
Deactivation should not delete history, but it does remove the site from new-transaction defaulting. Testing should confirm the system either blocks or warns on deactivation while open items exist, and that open invoices remain processable afterward.
How do you test tax registration at the site level?
▼
Create a site in a taxable jurisdiction, assign the required registration, and confirm it drives tax determination on invoices billed to that site. Negative tests should confirm a missing required registration is flagged rather than silently omitted.
Can a customer account have a site-level credit limit different from the customer master?
▼
Yes, a site can carry a credit limit override that applies to transactions against that specific site. This interacts with the broader credit check process — see Oracle Credit Management Testing for how the check itself is tested.
How do you test duplicate site detection?
▼
Attempt to create a second site with a matching address and business purpose against the same account, and confirm the system flags or prevents the duplicate rather than silently creating a fragmented second record.
Does Redwood change site testing?
▼
Redwood redesigns the customer and site pages, which breaks selector-based automation even when the underlying defaulting logic is unchanged. SyntraFlow understands Redwood pages semantically and self-heals, so site creation and defaulting assertions keep running through UI redesigns.
How do site changes get regression tested after a quarterly update?
▼
SyntraFlow's Release Intelligence maps Oracle's release notes to your site configuration and recommends the specific creation and defaulting scenarios affected, rather than requiring a full re-run of every case.
Can sites be created via import or API?
▼
Yes. Oracle supports site creation through the UI, FBDI file-based import, and REST APIs. A complete test suite validates all three produce equivalent site records, since bulk conversions and integrations rely on the import and API paths.
How does SyntraFlow automate site testing?
▼
SyntraFlow provisions customers and sites through the Oracle Data Vault, runs creation and defaulting scenarios across UI, FBDI, and REST, and asserts the actual default that lands on the invoice or receipt — with evidence captured for every run.
Strengthen Your Oracle Receivables Test Coverage
Identify gaps in your customer account site test suite, automate high-risk defaulting scenarios, and prepare for Oracle quarterly updates with SyntraFlow. See it run against site cases like yours.