The safest way to connect an approved spend request to corporate gifting is to treat approval, execution, and accounting as three distinct records joined by stable identifiers. SAP Concur Request can establish that planned spend passed the organization’s configured workflow; the gifting system executes the recipient experience and fulfillment; finance then reconciles invoices, shipments, cancellations, replacements, and credits. The design works only when no system is asked to prove what it cannot see.
The short answer: pass an authorization envelope, not a shadow expense system
Start with an approved request ID, approved ceiling, currency, cost object, purpose, owner, permitted recipient class, and approval timestamp. Send only the fields the gifting operator needs. Give every gifting order a separate immutable order ID and store the request ID as a reference. When fulfillment closes, return a settlement packet containing the order ID, request ID, actual merchandise and service charges, tax, shipping, credits, cancellation outcome, and evidence links.
Do not claim that a SAP Concur approval automatically creates a Giftpack order unless your organization has implemented and tested that connection. Giftpack’s public material supports configurable recipient choice and global or local fulfillment; it does not publicly document a native Concur Request connector. The honest implementation choices are a controlled manual handoff, a reviewed file exchange, or a customer-built API workflow using the entitlements and scopes actually licensed in both environments.
The control principle is simple: authorization is not a purchase, a purchase is not a delivery, and a delivery is not a final accounting entry. A reliable workflow retains all four states and the transitions among them.
What Concur Request can prove—and where its evidence stops
SAP describes Concur Request as a pre-spend request and approval product that helps organizations apply policy, manage budgets, and compare planned with actual spend when used with Concur Expense. Current SAP Help documentation also explains that an approved request can be applied to an expense report. The Request v4 documentation exposes request and workflow resources, but it explicitly warns that access to documentation does not grant API access and that the client must purchase Concur Request. OAuth2 and company- or user-level permissions remain implementation prerequisites.
That evidence supports four safe statements. A configured Concur workflow can record a request, route it for approval, maintain an approval status, and expose approved-request data through supported product or API paths available to the customer. It does not, by itself, prove that a gift was ordered, that the recipient accepted it, that a parcel arrived, that a supplier invoice is correct, or that a cost is allowable under local tax, ethics, employment, or privacy rules.
Build the boundary deliberately. The request remains the authorization record. The gifting platform remains the execution record. The accounting or expense system remains the settlement record. A data warehouse may combine them for reporting, but it should not overwrite the source histories.
Last verified: October 13, 2026. Geography: global operating pattern; actual product configuration, licensing, data residency, employment rules, tax treatment, and public-sector restrictions vary by entity and market. Method: official SAP Concur product, Help, integration, developer, and release materials plus Giftpack’s public product pages. Gap: no public evidence of a native Giftpack–SAP Concur connector, so every automated path below is a design pattern requiring customer validation.
Choose the handoff pattern before choosing fields
The right integration level depends on frequency, risk, and operational maturity. A low-volume executive program may be safer with a dual-reviewed manual handoff than with an unmonitored script. A high-volume program with stable policies may justify API orchestration, but only after the team proves idempotency, permission boundaries, error recovery, and reconciliation.
| Pattern | Best fit | Main control | Tradeoff |
|---|---|---|---|
| Controlled manual handoff | Low volume, high judgment, early pilot | Two-person review of approved request and order | Slower and vulnerable to transcription errors |
| Reviewed file exchange | Recurring batches with stable field definitions | Versioned schema, totals, row counts, reject file | Latency and replay management |
| API orchestration | High volume, fast decisions, mature operations | OAuth scopes, idempotency keys, status ledger, alerts | Engineering, entitlement, and monitoring cost |
| Gifting-platform intake first | Recipient choice precedes final spend | Reserve ceiling, then reconcile actual selection | Approval may need amendment if landed cost changes |
Use one pattern for the pilot and define an explicit promotion gate. For example, move from manual to file exchange only after thirty consecutive cases reconcile without an unexplained variance, every rejection has an owner, and finance can reproduce the ledger from retained evidence. Move from file to API only after a replay test proves that the same approved request cannot create two active orders.
Design a minimal authorization envelope
Do not export an entire request record because the downstream team might someday need it. Start with purpose limitation. Finance defines the authorization fields, IT maps them, privacy reviews personal data, and gifting operations confirms what is necessary to execute.
| Field | Purpose | Owner | Validation |
|---|---|---|---|
| request_id | Immutable link to approval | Finance systems | Unique, present, never reused |
| approval_status and approved_at | Prove the current authorization state | Request workflow owner | Approved state only; timestamp retained |
| approved_amount and currency | Set the spend ceiling | Finance | Positive amount; ISO currency; no silent conversion |
| cost_object and entity | Route accounting and accountability | Controller | Active master-data value |
| program_code and business_purpose | Explain why the gift exists | Program owner | Controlled code plus concise description |
| recipient_class and market | Apply eligibility, ethics, and catalog rules | Legal or policy owner | Allowed combination; no free-text workaround |
| request_owner and expires_at | Provide accountability and stop stale execution | Business owner | Active owner; future expiry |
Keep recipient name, address, email, dietary preference, and gift choice out of the authorization envelope unless the approval decision truly requires them. A program can often approve a recipient class, market, count, and ceiling before collecting personal details. The gifting step can then collect the minimum delivery information through a controlled recipient flow. Read the recipient-data operations guide for retention and deletion design, but have local counsel and privacy owners determine the applicable rules.
Create a separate mapping register. It should show the source field, downstream field, transformation, allowed null behavior, system owner, and test case. If a cost center is retired, the interface should reject the order rather than substitute a default. If currency is missing, stop; do not assume the entity’s base currency. If the approved amount includes shipping but the gifting quote separates it, document the comparison formula.
Run the workflow as a state machine
Treat each transition as a controlled event rather than a row copied between systems.
-
Request drafted. The program owner states the business purpose, recipient class, market, estimated count, ceiling, currency, desired delivery window, and cost object. Personal recipient data is not needed at this stage unless policy requires it.
-
Request approved. The workflow completes all required approval steps. The integration checks the current status rather than trusting an email, screenshot, or stale export.
-
Authorization reserved. The handoff service creates an authorization record keyed by request ID and version. It records the exact approved ceiling and expiry. No gift order exists yet.
-
Order proposed. Gifting operations chooses catalog rules, recipient-choice settings, delivery markets, budget allocation, and exception handling. The proposed landed cost must fit the authorization rule.
-
Order committed. A unique gifting order ID is created. The service writes the request ID into the order’s reference field and writes the order ID back to the control ledger. This write-back need not alter the source approval; it can be an external crosswalk.
-
Fulfillment observed. The ledger records invitations, selections, address completion, shipment, delivery, expiry, decline, cancellation, replacement, and return as distinct statuses. No single status should masquerade as financial settlement.
-
Invoice and credits received. Finance compares charges with fulfilled outcomes and contractual terms. Credits remain linked to the original order and accounting period.
-
Case reconciled. The owner closes the case only when the approved ceiling, order totals, invoice, tax, shipping, refunds, replacements, and ledger status agree within the documented tolerance.
The interface should be monotonic where possible: a record may progress from reserved to committed to fulfilled to reconciled, while exceptions create linked events instead of erasing history. A cancellation after shipment is not a return to “not ordered.” It is an order plus a cancellation request plus a carrier outcome plus any credit.
Prevent duplicates with three identifiers and one replay rule
Use an immutable request ID, an immutable order ID, and an idempotency key for the creation attempt. The idempotency key should be derived from stable business inputs such as request ID, approved version, program code, and execution sequence. Do not derive it from the current time alone.
Before creating an order, the orchestration layer checks whether that idempotency key already has a terminal or in-flight result. If it does, return the existing result. If the previous outcome is unknown because of a timeout, query the original operation or search the target using the same key. Never rotate the key and retry blindly; that converts uncertainty into a possible duplicate.
Duplicate-expense exception playbook
-
Freeze the affected request and order references; do not delete either record.
-
Determine whether there are two orders, two invoices, two expense entries, or only duplicate reporting rows.
-
Trace idempotency keys, timestamps, operators, invoice numbers, credits, and shipment outcomes.
-
Cancel the unfulfilled duplicate when contractually possible. If both fulfilled, route the case through the approved recovery owner.
-
Post a correction or credit through the accounting process; never edit the source evidence to make the duplicate disappear.
-
Add the root cause and a regression test before reopening automation.
The acceptance test is not “the API returned 200.” It is “one approved version created no more than one active order, and every uncertain response was reconciled without a new key.”
Build a reconciliation packet finance can reproduce
A strong packet lets a reviewer begin with either the request or the invoice and reach the same conclusion. Store stable references, not screenshots alone.
The authorization section should contain request ID, approved version, approval status and timestamp, approver chain or retained workflow reference, ceiling, currency, entity, cost object, business purpose, program code, recipient class, and expiry. The execution section should contain order ID, catalog or campaign version, order owner, recipient count, invited and selected counts, shipment and delivery outcomes, cancellations, replacements, and returns. The settlement section should contain supplier invoice number, invoice date, merchandise amount, service fee, shipping, tax, duties if applicable, credits, net payable, currency, exchange-rate source when converted, and accounting document reference.
Add three formulas to the control ledger:
-
Authorization variance: committed amount minus approved ceiling. A positive value blocks commitment or requires a documented amendment.
-
Invoice variance: invoiced gross amount minus the contractually chargeable order total. The formula must define whether taxes, duties, and shipping are included.
-
Open recovery value: charges associated with canceled, lost, damaged, returned, or rejected outcomes that do not yet have a final credit or approved write-off.
Do not force every variance to zero. Currency conversion timing, taxes, duty assessment, recipient substitutions, and partial credits can create legitimate differences. Instead, define tolerances by program and market, require a reason code, name the decision owner, and retain the resolution.
For a broader control design, the global gifting operations hub can help teams connect governance, fulfillment, and measurement. It is operational guidance, not accounting, legal, or tax advice.
Hypothetical case 1: regional customer event
Scenario. A regional marketing team plans a customer workshop for 120 eligible attendees in three countries. It requests a ceiling of USD 18,000 covering gifts, packaging, standard shipping, and expected tax. The request is approved ten weeks before the event. The team wants recipient choice, but it does not yet have delivery addresses.
Decision. Finance approves the recipient class, markets, count, purpose, ceiling, and cost object. The handoff exports no recipient names. Gifting operations creates a recipient-choice campaign with a per-person product ceiling and an overall reserve below the approved amount. Recipients provide delivery data in the execution flow. The order crosswalk stores the Concur request ID, campaign ID, and version.
Alternative and tradeoff. A preselected bulk shipment to each event venue would reduce address collection and potentially lower unit shipping cost, but it would increase inventory, pickup, substitution, and leftover handling. Individual delivery supports choice and remote attendance, but it increases completion follow-up and cross-border variance. The team chooses recipient choice because attendance format is mixed and documents the extra operational reserve.
Failure and recovery. Twenty invitations expire and five accepted parcels are returned. The program owner does not count all 120 invitations as delivered gifts. Gifting operations closes expired invitations, records returns separately, and determines whether replacements remain within the deadline. Finance reconciles actual chargeable outcomes, posted credits, and any approved exception. A late customs charge that pushes the total over the ceiling triggers an amendment or a documented rejection before payment.
Acceptance evidence. The packet contains the approved request, market-level count, campaign configuration, order crosswalk, invitation and delivery summary, return cases, supplier invoice, credits, variance explanation, and controller signoff. A reviewer can reproduce the net payable without receiving unnecessary recipient address data.
Hypothetical case 2: employee milestone program
Scenario. People Operations runs a monthly service-anniversary program across four entities. The annual policy is approved, but each month requires a budget authorization based on the eligible population. The source HR list may change because of leave, termination, or corrected service dates.
Decision. The monthly Concur request contains only the entity, month, eligible count, value tier, expected landed cost, currency, cost center, policy reference, and owner. HR keeps the employee-level eligibility list in its governed environment. After approval, a controlled process passes only the minimum necessary employee records to the gifting workflow. The batch ID combines request ID, eligibility snapshot version, and month.
Alternative and tradeoff. A single annual order is simpler, but it reserves too much personal data and makes leaver recovery difficult. Monthly batches require more operations work, yet they create clearer cutoffs and reconciliation. The team chooses monthly batches and automates them only after two manual cycles pass.
Failure and recovery. The first file transfer times out after the target accepts some rows. The operator does not create a new batch. IT queries the existing batch ID, compares accepted and rejected row identifiers, and resubmits only through the documented same-ID recovery path. One employee becomes ineligible before selection; HR owns the decision, the invitation is canceled if contractually possible, and the ledger records the policy reason without exposing employment details to unnecessary viewers.
Acceptance evidence. Finance verifies one active order per approved monthly batch, total selected value within the ceiling, rejected rows resolved, ineligible cases closed, replacements linked, invoice lines matched, and credits posted. HR verifies eligibility and minimization. IT verifies the replay test and access logs. Gifting operations verifies recipient outcomes and support cases.
Test reversals, permissions, and evidence before go-live
Happy-path demonstrations are insufficient. Run a test set that includes a request sent back, an approved request recalled or canceled where the configuration permits, a ceiling reduction after order proposal, an expired authorization, an inactive cost center, missing currency, a duplicate file, an API timeout with unknown outcome, partial recipient acceptance, a lost parcel, a replacement, a return, a supplier credit, and a closed accounting period.
Separate permissions. Request approvers should not automatically gain access to recipient addresses. Gifting support should not be able to change approved ceilings. Integration credentials should have only the scopes required for the chosen operation. Finance reviewers need settlement evidence but not every personalization response. System administrators should not be the sole business approvers.
For each test, record the input, expected behavior, actual behavior, owner, evidence location, and disposition. A failed test must produce a recovery step and a new test version; changing the expected outcome after failure is not acceptance.
Use these minimum go-live gates:
-
Product and API entitlements confirmed by the customer’s SAP Concur administrator and implementation owner.
-
Current OAuth2 flow, scopes, credential rotation, and regional endpoint handling validated.
-
Field map approved by finance, IT, privacy, and gifting operations.
-
Same-key replay creates no second active order.
-
Unknown write outcome is reconciled through lookup before retry.
-
Amount, currency, entity, and cost object failures block execution.
-
Cancellations, returns, replacements, credits, and write-offs remain linked to the original order.
-
Recipient data retention and deletion are assigned to accountable owners.
-
Finance can reproduce the net payable from retained evidence.
-
Manual fallback and escalation contacts are tested.
Operating ownership after launch
Finance owns approval design, spend ceilings, tolerances, accounting treatment, and reconciliation acceptance. The program owner owns purpose, recipient class, timing, and exceptions. IT owns authentication, mappings, idempotency, monitoring, and technical recovery. Privacy and legal owners define data, ethics, employment, and cross-border boundaries. Gifting operations owns campaign configuration, recipient support, fulfillment status, and supplier evidence. Internal audit may test the control, but it should not operate it.
Review three queues at a defined cadence: approved requests with no order, active orders with no recent event, and invoices or credits with no closed reconciliation. Add an aging threshold and named escalation owner to each queue. A dashboard without an owner is only a list.
Measure control quality as well as speed. Useful indicators include median approval-to-order time, duplicate-prevention interventions, unknown-write recoveries, percent of orders within ceiling, open recovery value, credit aging, delivery completion by market, and percent of cases reproducible from retained evidence. Never use delivery rate alone as proof of recipient satisfaction or program impact.
Sources, verification date, and known gaps
Primary sources reviewed through October 13, 2026 include SAP Concur’s official Concur Request product page, SAP Help documentation for applying an approved request to an expense report and Request approval statuses, SAP’s official integration page, SAP Developer material for Request v4 and OAuth2, and SAP release information about legacy Request API decommissioning. Giftpack capability statements are limited to its official home, how-it-works, and personal-gifting pages.
The source record supports workflow and design claims, not a claim that every SAP Concur tenant has the same fields, statuses, API rights, or configuration. It also does not prove a native Giftpack connector, automatic invoice matching, tax treatment, or compliance in any jurisdiction. Validate licensing, scopes, endpoint behavior, data location, policy, contract terms, and accounting with the responsible owners before production.
Close the loop without turning either platform into the wrong system
The durable design keeps the Concur request as authorization, the gifting order as execution, and the accounting record as settlement. Stable identifiers, a minimal authorization envelope, same-key replay, explicit reversals, and reproducible reconciliation matter more than a visually seamless demo. Start with the least complex handoff that meets the risk and volume, then promote only after evidence shows the next level can be operated safely.
If Giftpack is part of the evaluated execution layer, test it against the same acceptance script as any alternative: recipient-choice controls, market coverage, permission boundaries, order references, fulfillment events, exception recovery, invoice detail, and exportable evidence. Confirm the purchased configuration and integration method directly. Giftpack should execute the approved gifting policy; it should not replace finance, tax, legal, privacy, employment, or SAP Concur administration decisions.