Receivables: prepare Oracle Fusion for the invoices and invoice-items resources

You need this guide if you intend to use the invoices or invoice-items resources. None of the configuration below comes with General Ledger — a tenant that posts journals perfectly well can still be unable to create a single invoice. Work through the connection guide first (it creates the integration user, its roles and its data access), then do this, then come back to the connection guide's Step 7 to enter the invoices settings — two always, and two more only in the cases noted below.

Four of the connection's settings are filled in from this work — the first two are required if you use invoices, the other two only in the cases noted:

Connection settingComes from
Receivables Business UnitSection A
Receivables Transaction SourceSection D
Invoice Transaction Type (only to force a type; blank lets Oracle apply its own default)Section C
Invoice Flexfield Context (only if your custom fields live under a context)Section K

⚠️ Receivables needs at least one legal entity, and a business unit must be associated with one. If you built your ledger with the Greenfield GL setup guide, it deliberately skipped legal entities — create one first, through the Legal Entity Configurator (Setup and Maintenance → Manage Legal Entity), before starting Section A.

All tasks below are reached from Setup and Maintenance → Setup: Financials → Search → Tasks unless a section says otherwise.

ℹ️ A functional area's task list defaults to Required Tasks and hides most of what it contains — switch the Show selector to All Tasks before searching. Oracle's task search is literal: a near-miss name returns nothing rather than a suggestion.

Order matters. Several steps are only reachable once an earlier one has been saved.


Section A — Business unit

Task: Manage Business Units.

The business unit is what scopes every Receivables setup below, and it is also the unit Oracle secures invoice visibility by.

⚠️ Assign every business function to the business unit in one pass. Adding a business function to a business unit that is already in use means redoing the dependent configuration underneath it. Decide the full set now, even the ones you do not need yet.

Record the business unit's name exactly as it appears — it is the value of the Receivables Business Unit connection setting, and it must match the business unit you grant data access on (connection guide, Step 3.3). The setting only affects creates: an invoice created under a business unit the grant does not cover is not visible to the connection afterwards.

Section B — Receivables System Options

Task: Manage Receivables System Options, scoped to the business unit.

Five tabs, and the ones that block a save are not the ones you would expect:

  • Billing and Revenue — application rule set, discount basis, default country, and whether the remit-to address prints.
  • Accounting — tax account, cross-currency rounding, realized gain/loss accounts. Oracle demands these even on a single-currency ledger. They are never posted to in that case, so any valid account satisfies the form.
  • Transactions — tax invoice printing, document number generation.
  • Customers — grouping rule and AutoInvoice options.
  • Cash Processing — you must touch this tab even though nothing on it needs changing. Its Require billing location for receipts checkbox is backed by a NOT NULL column that starts out null, so an untouched checkbox is neither checked nor unchecked and the whole page refuses to save with You must provide a value for the SiteRequiredFlag attribute — an error that names neither this tab nor this field. Click the checkbox to check it, then click again to uncheck it; that writes an explicit "no" and the save goes through.

Section C — Payment terms and transaction types

Tasks: Manage Receivables Payment Terms, Manage Transaction Types.

Both are usually seeded. Verify rather than assume:

  • A transaction type must have Open Receivable = Yes and Post to GL = Yes. Both columns are hidden by default in the list view — add them and check, rather than trusting the defaults.
  • Payment terms are optional on a create: Oracle defaults them from the customer's profile when the request omits them.

Record the transaction type's name if you want to force one — that is the value of the Invoice Transaction Type connection setting (for example the seeded Invoice). Leave the setting blank to let Oracle apply its own default transaction type. The name must match this task's list exactly, and credit memos are a different document type that this connector cannot create.

Section D — Transaction source

Task: Manage Transaction Sources.

Seeded sources are typically all Type = Imported. A manual source usually has to be created, and it is what the connector needs.

Create one with:

  • Type = Manual
  • Active, with a from-date that covers the dates you will invoice
  • Automatic transaction numbering — decide once, because Oracle locks this flag as soon as the source has a transaction. Enabled: Oracle numbers every invoice and ignores any number sent on a create. Disabled: the number sent is kept, every create must supply one, and a number already used is refused
  • A standard transaction type
  • Last Transaction Number — set it to 1 or higher. Oracle creates a database sequence starting from this number, and a sequence cannot start below 1, so 0 — as well as blank — fails the save with an ORA-04006 sequence error

Record the source's name — it is the value of the Receivables Transaction Source connection setting.

Section E — AutoAccounting rules

Task: Manage AutoAccounting Rules.

AutoAccounting derives the accounting combination for every distribution the invoice generates. One rule per account type; at minimum Receivable, Revenue, Tax, Freight and AutoInvoice Clearing. (Unbilled Receivable and Unearned Revenue are only needed if you use revenue scheduling rules.)

Each rule needs a value for every accounting-flexfield segment.

⚠️ There is no Constant option in the Value Source list — leave Value Source blank instead. The dropdown offers only Transaction Types, Salespersons, Site and blank, so a constant looks impossible. It is not: blank Value Source is the constant case — leave it empty and type the segment value into the separate Constant Value column. Do that for every segment you want fixed.

The alternative is to give the transaction type Reference Accounts for Oracle to derive from, but that is only worth it when the accounts genuinely vary by transaction type. For a minimal setup, blank Value Source plus Constant Value is the shorter route.

Any account class you omit is still derived by AutoAccounting, so an invoice will produce a Receivable distribution even if you only configured Revenue.

Section F — Remit-to address

Task: Manage Remit-to Addresses.

Create one. After the first save, a Receipt from Criteria region appears — it does not exist on the create form. Re-open the record and add at least one row (country, optionally state and a postal-code range).

This is ordinary setup, not a fix for anything. In particular it is not the cause of AR-855322, despite that error naming the remit-to default — see the date-effectivity box in Section G for what actually causes it.

Section G — Customer and bill-to site

Task: Manage Customers.

Create a customer with a registry ID, an account number, an account type, and a site carrying the Bill to purpose marked Primary. Add a Ship to purpose as well if you want tax determination to behave the way it would for a real tenant.

Record the account number — that is the value an invoice create must send as customer.display_id.

⚠️ The one that costs days: site date effectivity

A customer's site purposes and its account-address-set assignment all carry a From Date equal to the day the customer was created, and From Date is read-only in Manage Customers.

Receivables filters bill-to sites by effective date against the transaction date. Create an invoice dated before the site existed and Oracle reports the site as non-existent:

AR-857620  The customer bill-to site you entered doesn't exist
AR-855322  (date-effectivity error on the remit-to default, same cause)

The message names the site, so the natural reaction is to go looking at site configuration — reference data sets, set assignments, remit-to postal ranges, business-unit determinants. It is none of those.

When Oracle says a record does not exist and that record demonstrably does, vary the date before you vary the configuration. Re-send the identical request with today's date; it discriminates the entire class in under a minute.

To read the dates: Manage Customers → the customer → Sites → click the blue site link → the purposes and their From Dates. There is no Business Unit column at that level, because the purposes are not business-unit scoped.

A second, independent cause worth checking — reference data sets. Customer sites are also scoped by a reference data set. The Account Address Set list may offer only ENTERPRISE, while payment terms, transaction types and transaction sources all live in Common Set. If the business unit's determinant points at a different set than the site actually lives in, the business unit cannot see the site.

Fix: Manage Business Units → select the business unit → Actions → Manage Set Assignments → row Customer Account Site → change the reference data set to match where the site lives.

This is genuinely worth correcting, but be clear that it is a separate problem from the date effectivity above — fixing it alone does not clear AR-857620.

Rule of thumb: when a list of values offers a reference data set that differs from the one you use everywhere else, do not dismiss it. Check the business unit's set assignment.

Section H — Open the Receivables periods

Receivables periods are separate from General Ledger periods. A tenant whose GL periods are open can still have every Receivables period in Never Opened, and an invoice create then fails with:

AR-855397  The accounting date isn't in an open or future-enterable period

Open them with the Open Receivables Accounting Period scheduled process (Navigator → Tools → Scheduled Processes → Schedule New Process), giving it the ledger and the period name.

One run opens every period from the current open one through the one you name, and sets the following period future-enterable. You do not have to run it month by month.

⚠️ Two navigation traps here, both live-verified:

  • Manage Accounting Periods is not a Setup and Maintenance task. It is transactional, under Navigator → General Accounting → Period Close. Searching the setup tasks for it finds nothing.
  • The GL-side Edit Accounting Period Statuses page cannot display a Never Opened period: its Status filter offers only All / Closed / Future Enterable / Open / Close Pending, and that "All" means all of those. An empty grid does not mean the periods are missing.

Section I — Business unit data access

Task: Manage Business Unit Data Access for Users (or the Business Unit security context in Manage Data Access for Users).

Add a row for the integration user the connector authenticates as (the connection guide's Step 1 user, named after the Client ID): the user, its Receivables role, security context Business unit, value = your business unit.

This is the same row as the connection guide's Step 3.3, not an additional grant — whichever guide you reach it from, there is one Business Unit row. This section is the fuller account of it; the box below is the part that is not in the connection guide.

The role alone is not enough — it grants the privilege with no business unit to exercise it on.

⚠️ Live-verified on the verification pod, and not something Oracle documents: for the integration user, Accounts Receivable Manager plus this business-unit row plus both scheduled processes was still not enough — the invoice list stayed empty and every invoice GET returned 404. Adding Application Implementation Consultant (ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB) to the same user made the business unit visible within a minute, and removing it made the list empty again. If your invoice reads return nothing after this section, assign that role too, re-run the two processes, and re-test. It is a broad role; whether a narrower one carries the same effect has not been established.

Then run both of these scheduled processes, in this order (Navigator → Tools → Scheduled Processes → Schedule New Process), waiting for each to reach Succeeded before starting the next:

  1. Send Pending LDAP Requests — Oracle documents this as the process that manages role provisioning and deprovisioning, finalizing the pending transactions your change created.
  2. Import User and Role Application Security Data.

⚠️ A role change is not live for a REST caller until Send Pending LDAP Requests has completed. In live verification the invoice list changed within a minute of that process finishing after a role was added or removed. Run Import User and Role Application Security Data after it as Oracle documents; do not skip either.

The Security Console is not a reliable place to verify the grant took effect. Users with Data Access can show the row while the grant is not yet live for a REST caller. Verify with an actual API read instead.

⏱️ Grants are applied asynchronously, so an empty invoice list in the first minutes after granting is expected — allow a few minutes after both processes succeed. Beyond that, more time will not change the outcome: re-check the grant itself, the role (see the box above), and that both processes ran.

Section J — Standard memo lines (the invoice-items resource)

Task: Manage Standard Memo Lines.

Memo lines are Oracle's construct for invoice lines that are not inventory items, and they are what the invoice-items resource returns. Oracle seeds a set of them, so there is usually nothing to do here — the resource works on a fresh tenant with no configuration at all.

Create additional memo lines only if you want your own catalogue. The resource is read-only through the API: memo lines are maintained here, not through Apideck.

Two things to know when referencing them on an invoice line:

  • Receivables matches a memo line on its exact, case-sensitive name. Send the name in item.code; the invoice item's id is rejected with AR-857629.
  • Some seeded memo lines are reserved for other document types — the chargeback and debit-memo-reversal lines among them — and Receivables refuses them on a customer invoice with the same AR-857629. Goods and Services is the general-purpose line in a default configuration.

Section K — Custom fields (optional)

Task: Manage Receivables Descriptive Flexfields.

The connector writes custom_fields to the segments of the Transactions descriptive flexfield (flexfield code RA_CUSTOMER_TRX) and reads them back from the same place. Nothing is stored until segments exist and the flexfield is deployed.

  1. Search by Flexfield Code RA_CUSTOMER_TRX, select the Transactions row and click Edit.
  2. Add a Global Segment per custom field (or a context and its context-sensitive segments if the tenant already organises them that way):
    • API Name — this is the value clients send as custom_fields[].id; record it exactly.
    • Data Type Character and a Table Column (ATTRIBUTE1, ATTRIBUTE2, ...).
    • Value Set — a Format Only character value set. If none exists, create one from the segment page (Module Receivables, Validation Type Format Only, Value Data Type Character, Value Subtype Text, Maximum Length 150).
    • Display Type Text Box; leave Required unchecked so invoices without custom fields still save.
  3. Save and Close, then, with the Transactions row selected, click Deploy Flexfield and wait for the deployment status to show a green check with today's date. Segments that are not deployed are invisible to the connector.

If you used a context rather than global segments, put its context code in the connector's Invoice Flexfield Context setting; leave the setting empty for global segments.

What about tax?

Fusion Tax is its own configuration layer (regime, tax, status, jurisdiction, rates, and the rules that decide whether a tax applies). Invoices can be created without it — they simply carry no tax, and total_tax comes back as 0.

If your invoices need tax, configure Fusion Tax before relying on the tax figures the API returns. A tenant with a tax regime defined but no applicability rules will still return zero tax on every invoice, because the tax is eliminated before it is ever applied — a zero total_tax is not by itself evidence that the connector is misreading anything.


Troubleshooting

Oracle errorCauseFix
AR-855397 — the accounting date isn't in an open or future-enterable periodNo Receivables period open for that date. GL periods are separate.Section H.
AR-857620 — the customer bill-to site you entered doesn't existAlmost always site date effectivity: the transaction date precedes the site's From Date. Occasionally a reference-data-set mismatch.Section G — vary the date first.
AR-855322 — date-effectivity error on the remit-to defaultSame cause as AR-857620; the remit-to default derives from the bill-to site.Section G.
AR-857629 — invalid memo lineThe line referenced a memo line by id, with the wrong case, or referenced one reserved for another document type.Section J.
ORA-04006 when saving a transaction sourceLast Transaction Number is 0 or blank; Oracle starts a sequence at that number and it cannot start below 1.Set it to 1 or higher — Section D.
Invoice creates succeed but lists come back emptyThe integration user has no Business Unit data access, or the grant has not been finalized by the two scheduled processes.Section I, then connection guide Step 7.
Every Receivables call returns 403Missing the Receivables role or the Access FSCM Integration Rest Service privilege, or the two scheduled processes have not run since the role was assigned.Connection guide, Step 2.

Once Sections A–J are done (and K, if you use custom fields), return to the connection guide and enter the settings from the table at the top of this guide in Step 7 — Receivables Business Unit and Receivables Transaction Source always, plus Invoice Transaction Type and Invoice Flexfield Context in the cases noted there.