CRM, academic system, finance and marketing
Strong key first, validated document, never a person in place of the contract
Reconciliation status per sale, enrollment and payment
Acquisition dashboard, audit and AI agent
What it solves
- Every CRM sale has its matching enrollment and payment, or an explicit reason why it does not.
- Enrollments with no CRM deal show up instead of disappearing from the funnel.
- The source of each enrollment is attributed by evidence, with the same person identity across all three systems.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- CRM, academic system and finance connected to Nekt (the academic data can come from a prepared query or a spreadsheet)
- An academic key in the CRM, such as the RA (student ID number), filled in before the sale is marked as won
- The school's rule: one sale generates one enrollment, or several
What you get
- A table per won deal with the linked enrollment, link method and reconciliation status
- A person and customer dimension with a validated document and identifiers from all three systems
- An acquisition dashboard with enrollment source and pending reconciliation items
- An AI agent that explains the mismatch in a specific case
Where to activate
Sales, enrollment and payment side by side, with source and reconciliation status by academic term.
Sales with no enrollment and enrollments with no sale for the sales team and the registrar's office to review.
Investigates a case: shows the deal, the enrollment, the receivables and which key matched each one.
Three or four sources with no common key. Start with the academic key in the CRM and the valid document rule. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The CRM records the deal with the guardian, the academic system records the student and finance records who paid. There is no common key, and the linking fields are filled in by hand. Matching by name or by any document attaches sales to the wrong customer; matching by person splits the contract in two when a parent pays for a child.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
CRM = sales process (deal, salesperson, stage). Academic system = official enrollment, student, class, contract and status. Finance = receivable, payer and payment. Marketing = source and campaign. One does not prove the other: a won deal does not prove an enrollment, and there can be enrollments with no CRM deal.
Link accounts receivable by contract or sale id, never by person. The payer (father, mother, company) is often different from the account holder and the student; joining by person and contract splits the same contract into two rows. Expose the payer as a column.
If the CRM stores the student's RA in a deal field, link the academic data only when the RA is unique in both sources. RA is text: keep leading zeros and never convert it to a number. A repeated RA stays unlinked, with a reason.
Try in order: the deal id stored in finance (for example, `numero_documento` in Omie), then a validated CPF or CNPJ (company tax ID) with a compatible product, then normalized email and phone. Record on each row which method matched.
Strip everything that is not a digit. Only a CPF with 11 digits or a CNPJ with 14 becomes a key. Any other length is a typo: treat it as no document and do not try to match, so the sale does not stick to the wrong customer.
Email: lowercase, no spaces. Phone: digits only, and remove the 55 country code only when more than 11 digits remain. Use a single phone reference table per person; two different logics have already cut off the area code thinking it was the country code.
Knowing it is the same person does not mean it is the same sale: a student can have several enrollments and a guardian several children. Keep one row per won deal and separate the identity link (it is the same person) from the reconciliation (it is this enrollment, from this sale).
Classify each case: reconciled, CRM only, academic only, finance only or ambiguous. An enrollment with no deal is not automatically an error (re-enrollment, walk-in, corporate); it is a category for the team to review.
The enrollment source comes from the strongest evidence for the same person: marketing UTM, then the support tag and channel, then the CRM source field. Recover UTMs embedded in `traffic_source` and in encoded payloads. When the source only stores the entry source, the model is single-touch, not multi-touch: state that.
Source has dozens of spellings for the same event. Use a mapping table from raw value to standardized source and another from source to expected channel, which audits the channel chosen by hand. Fields that mix several kinds of information stay out of attribution.
Which system answers what
And which key links each one.
Definitions
Pitfalls that already happened
Hundreds of deals had the CNPJ field filled in with the wrong length and matched the wrong customer.
Only accept 11 or 14 digits after cleanup; everything else becomes no document.
When finance was joined by person, thousands of contracts where the guardian paid for the student became two rows and revenue doubled.
Link accounts receivable by contract id only.
Some finance receivables had no contract number, and matching by document alone picked the wrong installment.
Match on document + payment date + issue date + amount, and exclude documented manual outliers before the trusted layer.
Customers billed through an unconnected gateway showed up as unpaid and triggered false alerts.
Check the deal's payment platform field before treating a missing payment as a problem.
People who used one email on the form and another at purchase showed up as sales outside the funnel, understating the return on lead capture.
Keep a dictionary of identifiers per person (emails, CRM ids and sales platform ids) and state the limit.
Hundreds of campaigns existed only in lead UTMs, with no spend recorded on any media platform.
Combine platform campaigns with UTMs in a dimension with a synthetic key and flag which ones have no cost.
Acceptance test
The case is done when every item passes.
- Every won deal in the period appears exactly once, and the sum of reconciliation statuses equals total sales.
- Every official enrollment in the period has a status: linked to a sale or enrollment with no deal.
- No link uses a document with a length other than 11 or 14 digits.
- The finance total by contract equals the finance total for the same slice, including contracts where the payer differs from the account holder.
- Every RA keeps the same number of characters as in the academic source, with leading zeros.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Sales, enrollment and payment reconciliation - CRM = sales process. Academic system = official enrollment, student, class and status. Finance = receivable, payer and payment. Marketing = source and campaign. - A won deal does not prove an enrollment. There can be enrollments with no CRM deal. - Lead, financial guardian and student can be different people. Do not call a CRM contact a student. - Finance links to the sale by contract id, never by person. The payer goes in its own column. - RA (student ID number) is text: keep leading zeros. Academic link only with an RA that is unique in both sources. - Link order: deal id in finance, validated document with compatible product, normalized email and phone. Record metodo_match. - Valid document: CPF (individual tax ID) with 11 digits or CNPJ (company tax ID) with 14 after cleanup. Other lengths = no document. - Phone: digits only; remove the 55 country code only when there are more than 11 digits. Email lowercase, no spaces. - Reconciliation status: reconciled, CRM only, academic only, finance only, ambiguous. - Enrollment source: marketing UTM, then support tag, then CRM source field. Single-touch model, not multi-touch. Per-client exceptions: - <client>: the RA is stored in the deal field <field> before the sale is marked as won. - <client>: the deal id is typed into the finance field <field>. - <client>: one sale generates <n> enrollments (one per class or course unit).
Build the "Sales, enrollment and payment reconciled" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/educacao/conciliacao-crm-sistema-academico-financeiro.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Sales platform instead of the academic system: person = normalized email, with a dictionary of emails and platform and CRM ids.
Contract with several items (course, lodging, insurance, flights): count distinct contracts and link finance by contract.
Customer = validated CNPJ, canonical name from finance, then from billing, then from the CRM.