Close Faster with
Ramp + Dynamics GP — Fully Automated

• A standard integration is a few hours of actual work, spread over several days.
• The days come from a mix of customer, Ramp, and eOne steps that each add calendar time. The technical work itself isn’t long.
• Set the expectation in days, not hours.

• The customer needs a SmartConnect plan that supports a GP connection plus an additional REST connection for Ramp. Both are required.
• SmartConnect version is an absolute requirement: if they already use SmartConnect, they have to be on SC21 version 1705 or higher.
• No SmartConnect today means a separate license purchase.
• Dynamics GP version: eOne strongly recommends GP 2018 or higher. This is a recommendation, not a hard gate. GP 2018 is the latest major GP release, it’s eight years old at this point, and it carries eight years of sub-releases and updates.

• Two options, both in the base package. The customer picks one. They’re mutually exclusive, not stacked.
• One account in one field.
• Segment filtering with cascading validation is the alternative. The customer configures the order the user picks segments in.
• Neither option lets the user select an invalid combination, and neither is better than the other on that point. The choice is about how the customer wants to code transactions, not about accuracy.

• AP payment application is included in the base package as of the 7/17 GP integration release.
• The AP transaction being applied to must be posted in GP. That’s a GP requirement, not a Ramp or eOne limitation.
• If that AP transaction isn’t posted yet, the payment errors on that sync attempt and retries automatically on the next cycle. No manual intervention needed.
• Once the AP transaction is posted, the next sync attempt succeeds and the payment integrates and applies normally.

Don’t call it a bidirectional sync. Bidirectional implies simultaneous edits to the same record in both systems, and that isn’t what happens. “Sync in both directions” or “Sync in either direction” is fine.

• Vendors: either direction, and the customer picks which system is master. After the one-time initial vendor migration, vendors run in one direction only going forward.
• GL and chart of accounts: GP to Ramp.
• Spend transactions, meaning card transactions, bills, and reimbursements: Ramp to GP.
• Sync status: flows back to Ramp so the user can see whether a record succeeded or failed.

• MEM (Multi-Entity Management) always requires a scoping estimate. No exceptions.
• True intercompany, meaning one Ramp invoice allocated or split across multiple GP companies, always requires a scoping estimate.
• Neither is a disqualification, and neither is a bigger or scarier project. Implementation time is similar.

A scoping conversation is needed if the customer meets any of the following criteria:

• They run MEM
• They need true intercompany routing, meaning one Ramp invoice allocated or split across multiple GP companies
• They want custom field mappings, transformations, or non-standard business logic
• They need non-standard writebacks, for example a check number written back to a posted payment, or a vendor-credit process
• Integration with additional third-party systems, for example Wennsoft
• Their GP is hosted. This may not change pricing, but requires coordination with the hosting provider
• A third-party app sits in the AP flow

• OAuth authentication and accounting connection setup between Ramp and GP
• Chart of accounts configuration, scoped to the relevant accounts
• Account assignment, either one account in one field or segment filtering, the customer’s choice
• GL account integration to Ramp’s GL field
• One-time initial vendor migration from GP into the new Ramp instance
• Ongoing vendor sync in the customer’s chosen direction
• Card transaction, bill, and reimbursement posting into GP
• AP payment application in GP
• Integration testing and scheduling
• Simple multi-company support: one Ramp invoice for Company A posts to Company A in GP