# How to integrate third-party billing systems with Salesforce Revenue Cloud Revenue Cloud or the billing system owns the invoice amount. Write down which number wins before you connect them. **Published:** 2026-01-27 **Canonical:** https://synconai.com/integrate-billing-revenue-cloud **Author:** SynconAI Architecture Team ## In short Revenue Cloud can own quote-to-cash, including the invoice, or a third-party billing system can own the invoice. One of them owns the number. Writing the same amount into both and hoping they match will split finance. Before the integration, write down which figure wins when they disagree, and send the other system a copy it does not edit. ## Sources - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs. - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged. ## What to take away - One owner for the invoice amount. Revenue Cloud can own quote-to-cash, or the billing system can own the invoice. - The other system stores a copy it does not edit. Adjustments happen in the owning system, then go out again. - Write the winner down before the integration. When the figures disagree, that sentence is the design. - A copy in Data 360 is still a copy. Add-on licences and usage limits do not make Data 360 the ledger. ## The guide Third-party billing and Salesforce Revenue Cloud can be connected without splitting finance, if one of them owns the invoice amount. Revenue Cloud can own quote-to-cash, from the quote through to the invoice. Or the billing system can own the invoice, and Revenue Cloud stops at the quote or the order that was sold. Both arrangements work. Writing the amount into both, and hoping a reconciliation job makes them the same, does not. You get two ledgers and a close that cannot finish. The failure is the close itself. A customer disputes a figure. The portal, which sits on the billing system, shows one amount. The order in Revenue Cloud shows another, because someone typed an adjustment into the copy and the integration pushed it back as if the two figures were peers. Finance asks which number is real. The integration team has a job that compares them and a ticket queue of differences. They do not have a sentence. The close waits on a meeting. The meeting cannot invent, in that week, an owner that should have been named before the first mapping workshop. Pick the owner before that workshop. Write one sentence where finance can see it: when the two figures disagree, this one wins, and the other is corrected. An integration that cannot point at that sentence is not ready to build. The same sentence has to match whatever you decided for an ERP in the path. One amount, one writer, including when SAP or another ledger is also in the picture. That neighbouring decision is in [Salesforce and an ERP](/integrate-salesforce-sap). Two projects that each pick a winner will meet at the close, and they will disagree. ## What each side is allowed to write If Revenue Cloud owns the invoice, the billing system may receive a copy for collection, for tax submission, or for a customer portal it already runs. It does not reprice that amount, reissue it, or push an adjustment back as if the two figures were equal. Adjustments are made in Revenue Cloud, then sent out again. The copy is replaced. It is not negotiated. If the billing system owns the invoice, Revenue Cloud may hold the quote, the products, and the order. The invoice number and the amount come back as a copy. Sales and service can read them. They do not edit them, and they do not create a second invoice on the account so the record looks complete. A second invoice is a second ledger. Usage, subscriptions, and credits follow the same rule. One calculator. The other screen displays the result. Say this in the interface contract, in one line each: this system creates the invoice, this system may store the number, this system must not change it. If a workshop cannot fill those lines, stop the workshop. Filling them with "both, and we reconcile" is not filling them. Reconciliation is a check. It is not an owner. A workshop that cannot choose is telling you the commercial decision has not been made. Building the connector anyway freezes the indecision into a sync, and the sync will still be running at the next close. The fields that ride along are the ones the reader needs, not the ones the source happens to have. Invoice number, amount, currency, date, status. Not the full tax engine, not every rating tier, not the internal comment a billing clerk typed. A wide copy feels safe and gives the non-owner more to edit. Every extra field is a field someone will "correct" locally. Keep the copy thin. The owner remains the place where the calculation lives. ## Adjustments, credits, and the second ledger An adjustment typed into the copy is the ordinary way the second ledger starts. The portal is where the customer is looking. A service agent, trying to help, changes the figure the customer can see. The integration is helpful, so it writes the change back. Revenue Cloud, or the billing system, now has a number it did not calculate. The next invoice run calculates the real number again. They differ. The difference looks like a defect in the connector. It is a defect in the permission to edit. Take the edit off the screen. If a person needs to grant a credit, they do it in the owning system, or they raise a request the owning system accepts under its own rules. The request is not a write to the amount. It is a message. When the owner accepts it, the new amount is sent out and the copy is replaced. When the owner refuses it, the copy stays as it was, and the agent tells the customer the refusal. The agent does not keep a local credit "so the customer sees something today". That local credit is the second ledger, and the customer will quote it. Usage and subscriptions are the same trap with more rows. A rating engine in the billing system and a rating engine in Revenue Cloud will both be sincere. They will not match, because they will not see the same inclusions, the same credits, or the same time window. Pick the calculator before you discuss the format of the file. A file format cannot reconcile two calculators. It can only deliver both of their answers into the close. Who is allowed to be the calculator is a commercial choice, and it belongs to finance, not to the team that owns the connector. The connector team can say what is expensive to change later. They should not pick the owner because one API was easier to call this sprint. Easier now is how the portal became the writer. Write the owner in the place finance already looks, next to the close checklist, so a future project cannot "just integrate" a second calculator without editing that page. ## Data 360 is not a second ledger You may also send a copy of billing data to Data 360. Data Cloud was renamed Data 360 on 14 October 2025. Salesforce says the name is new and the product is unchanged, and that you may still see Data Cloud in the application and the documentation. Some Data 360 features are offered as add-on licences, and some have usage limits, though many limits can be adjusted. Plan the volume and the licence if the copy is large. The licence does not make Data 360 the owner of the invoice. A figure in Data 360 that disagrees with the owner is a bad copy. Correct the copy. Do not open a meeting to decide which one finance should believe. You already wrote that down. A report that prefers the Data 360 figure because it is easier to query has quietly appointed a new ledger. Point the report at the owner, or label the report as a copy with a time on it. An unlabelled copy will be pasted into the close pack, and then you have three numbers. ::: warn Add-on licences and a large copy do not make Data 360 the ledger. If a report, a journey, or an agent treats the copy as the amount the customer owes, you have created another writer. Correct the copy from the owner. ::: Volume is a planning fact, not a design. If the usage limits bite, the answer is to change the licence or to send less, not to let the billing system and Revenue Cloud both keep "the" amount so Data 360 can be topped up from whichever is convenient. Convenience refills the disagreement. Send from the owner only. ## A check is not a design A daily check that the copy matches the owner is worth running. Mismatches go to a queue a person reads, and that person fixes the copy or raises a defect in the connector. The check is not permission for both systems to create the amount. Reconciliation after the fact is how two writers survive until the first audit. The queue should be small. A queue that is large every day is not a monitoring success. It is evidence the non-owner is still writing, or the copy job is dropping rows. Find which. Do not staff a permanent team to explain differences that a single writer would not create. The person on that queue needs the sentence. When the figures disagree, the owner wins, the copy is replaced, and a local edit is a defect to remove, not a difference to split. If the person is asked to "use judgement", the sentence was never issued. Judgement is a second policy. It will differ by who is on shift, and the close will inherit the shift. Attribute ownership, including who funds the check after the project that built it has gone, sits with the rest of the estate in [integration at programme level](/insights/enterprise-salesforce-integration-best-practices). A check with no owner will be the first thing cut, and the two ledgers will drift until a customer or an auditor notices. Put the check on a named person's week. Keep it after go-live. Do not confuse its existence with permission to write. Do the writing before the connector. After go-live, the disagreement shows up in a close, which is the worst week to decide who was allowed to be right. The sentence is cheap in the workshop. It is the whole design. ## What finance should be able to point at The sentence is short enough to sit on the close checklist. This system creates the invoice. This system stores a copy. This system must not change the amount. When they disagree, the named owner wins and the copy is replaced. The daily check has a named reader. A difference is a defect, not a negotiation. If a new project wants a second calculator, it edits this page first, in front of finance, before it opens a mapping workshop. A project that cannot get that edit does not get a connector. Put the portal on the same page. If the portal is the billing system and the billing system is the copy, the portal does not become the owner because that is where customers look. Customers look where you sent them. You can send them a number you do not let them, or a service agent, rewrite. The rewrite is the second ledger. Removing the field from the screen is a product decision, and it belongs in the same week as the sentence. Leaving it for a later UX pass is how the close inherits a text box. Read five disputed invoices the first month, with finance, against the sentence. If any dispute was caused by a write from the non-owner, the interface still allows it. Stop that write. Do not add a smarter reconciliation to explain it. The check is there to catch a broken copy. It is not there to launder a second writer into the close pack. A dispute that finance cannot trace to the owner, in one step, means the sentence is not yet how the org behaves. ## Questions ### Can Revenue Cloud and a billing system both own the invoice amount? No. Revenue Cloud can own quote-to-cash, including the invoice, or the billing system can own the invoice. One of them writes the number, and the other stores a copy it does not edit. Two calculators will both be sincere and they will not match. A reconciliation job does not turn them into one ledger. It turns the difference into a queue, and the close waits on that queue. ### What should we agree before building the integration? Which figure wins when they disagree, and which system is then corrected. Write it where finance can see it, before the mapping workshop. Also write who creates the invoice, who may store the number, and who must not change it. If the workshop can only say that both sides write and someone reconciles, stop. That is not a contract. It is the close, postponed. ### Where do adjustments happen? In the owning system. Then the copy is sent again. An adjustment typed into the copy and pushed back creates a second ledger. Take the edit off the screen the non-owner shows. A credit is a request the owner accepts or refuses under its own rules. A local credit, added so the customer sees something today, is the figure the customer will quote, and it will not match the next invoice run. ### Does Data 360 become the billing system of record if we load invoices there? No. Data Cloud was renamed Data 360 on 14 October 2025. Some of its features are add-on licences and some have usage limits, and a copy held there is still a copy. If it disagrees with the owner, correct the copy. A report that prefers the Data 360 figure because it is easier to query has appointed a new ledger. Label it as a copy with a time, or point the report at the owner. ### Is a nightly reconciliation enough? A check that the copy matches the owner is useful, on a queue a person reads, and it is not a design that allows both systems to create the amount. Decide the owner before you connect them. A queue that is large every day means the non-owner is still writing, or the copy is dropping rows. Do not staff a permanent team to explain differences a single writer would not create. The person on the queue applies the sentence and does not invent a new one per shift. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Revenue Cloud Advanced (https://synconai.com/salesforce-revenue-cloud-advanced).